Configuring Smart Client to Work with HTTPS/SSL

  1. Configure Web Central server to work with HTTPS/SSL.
    See http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html.
  2. Configure the computer where Smart Client is installed by installing the Web Central server security certificate for the current user:
  1. Start Internet Explorer.
  2. Enter the URL of the Web Central server, for example: https://localhost:8443/archibus/.
  3. The Internet Explorer will show “There is a problem with this website's security certificate.” page:

  4. Click on “Continue to this website (not recommended).” link. Web Central will load, but with an error in the address line as shown below.

  5. Click on “Certificate Error” , and then click on "View certificates".

  6. Click on “Install Certificate…”. Click “Next”, accept all defaults, and click “Finish”.
  7. You will see a message that the import was successful.

  8. Click “OK”.
  9. Close Internet Explorer.
  10. Start Internet Explorer.
  11. Enter the URL of the Web Central server, for example: https://localhost:8443/archibus/.
  12. You will see the Web Central Sign In page, without any error messages.
  13. Verify that you can sign in and use the Process Navigator.
  1. You can now start Smart Client and use the URL of the Web Central server, for example: https://localhost:8443/archibus/.

For the production deployment, you should consider using chain trust versus peer trust. See in How To: Create and Install Temporary Certificates in WCF for Message Security During Development in http://wcfsecurity.codeplex.com

Troubleshooting

If you see error message “The Name of the Security Certificate Is Invalid or Does Not Match the Name of the Site”, that means, according to http://support.microsoft.com/kb/813618, that:

“The common name that you specified when you generated the certificate request for that Web site does not match the URL that is used to access the Web site. For example, if you access the site by typing an IP address or the server name, but the common name that is specified in the certificate request is www.adatum.com, you receive the security message.”

Excerpts from http://fusesource.com/docs/broker/5.3/security/i382183.html:

HTTPS URL integrity check

The basic idea of the URL integrity check is that the server certificate’s identity must match the server host name. This integrity check has an important impact on how you generate X.509 certificates for HTTPS: the certificate identity (usually the certificate subject DN’s common name) must match the host name on which the HTTPS server is deployed.

The URL integrity check is designed to prevent man-in-the-middle attacks.

Using commonName

The usual way to specify the certificate identity (for the purpose of the URL integrity check) is through the Common Name (CN) in the subject DN of the certificate.

For example, if a server supports secure TLS connections at the following URL:

https://www.progress.com/secure

The corresponding server certificate would have the following subject DN:

C=IE,ST=Co. Dublin,L=Dublin,O=Progress,
OU=System,CN=www.progress.com

Where the CN has been set to the host name, www.progress.com.

For details of how to set the subject DN in a new certificate, see Use the CA to Create Signed Certificates in a Java Keystore

 

References

Special Requirements on HTTPS Certificates

Security Alert: The Name of the Security Certificate Is Invalid or Does Not Match the Name of the Site

How To: Create and Install Temporary Certificates in WCF for Message Security During Development

Differences Between Service Certificate Validation Done by Internet Explorer and WCF

Copyright © 1984-2014, ARCHIBUS, Inc. All rights reserved.