Configuring Smart Client to Work with HTTPS/TLS
Configuring Smart Client to Work with HTTPS/TLS
Smart Client supports these protocols when configured to use HTTPS:
- TLS 1.0 (requires .Net 4.0 or .Net 4.5)
- TLS 1.1 (requires .Net 4.5)
- TLS 1.2 (requires .Net 4.5)
Note: Smart Client does not support SSL. For information on SSL, see this link from Microsoft: https://technet.microsoft.com/en-us/library/security/3009008.aspx?f=255&MSPPError=-2147217396
Procedure
- Configure Web Central server to work with HTTPS/TLS. See http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html .
- Configure the computer where Smart Client is installed by installing the Web Central server security certificate for the current user. See https://support.securly.com/hc/en-us/articles/206081828-How-to-manually-install-the-Securly-SSL-certificate-in-Chrome
- 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
If Using Microsoft .Net 4.5 and Later
Smart Client supports the TLS security protocol of Microsoft .Net 4.5 and later. If you have not installed .Net 4.5, you cannot use TLS 1.2.
If you are using this version, configure the Web service and set the special flag in
SmartClient config
.
-
Check the configuration file
SmartClient.Common.dll.config
-
Find the section
<Settings />
-
Find the field
SecurityProtocol
- Set the selected version of TLS.
Example of the
<Settings>
section:
<Settings
InstallationType="Full"
Locale="en-US"
Username="AI"
Password="f@y^*-m1357902468a ZXw=+"
DefaultAppServerLocation="http://localhost:8080/archibus/"
LocalDrawingFilesFolder="C:\Users\Public\Archibus\projects\my-drawings"
DefaultProject="HQ-Sybase-WebEdition"
RememberCredentials="true"
SecurityProtocol="Tls12"
>
If you receive the error message "incorrect format of configuration file" after changing
SecurityProtocol
to TLS1.2 (
SecurityProtocol="Tls12"
), make sure that you have the right setting according to the .NET version used.
For examples of TLS versions:
- Tls
- Tls11
- Tls12 (base protocol TLS 1.0; protocol TLS 1.1 and TLS 1.2)
see https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
Troubleshooting
Invalid Security Certificate
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