- Does WSEMS use SSL pinning?
- Yes, it does. To explain the process a bit more, the ssl pinning is the act of verifying a server certificate by comparing it to the exact certificate that is expected. We “install” a certificate on the EMS (copying the cert to the ems device, and specifying the cert in config.json), EMS will then check all incoming certs against the cert in config.json, looking for an exact match and verifying the certificate chain.
- Should it be expected that the client, WSEMS.exe, installs the client certificate in order to validate the server certificate using SSL pinning?
- This does not happen automatically, the cert must be downloaded and manually added to the device. The config must also be manually updated.
- If so, how we issue the client cert for WSEMS.exe? Does it need to be issued the same way as the server certificate?
- If talking about pinning, one could use either the server cert directly, or the root cert (recommended). The root cert is the public cert of the signing authority, e.g. if the server uses a verisign issued cert, one can verify the authenticity of the signer by having the verisign public cert. If talking about client certs (2 way auth, client verifies server, server verifies client) then the process is a little different.
- What happens when the client certificate expires? Do all the devices go offline when the client certificate expires?
- The device won’t connect with a failure to authorize. Once the server cert expires, the server cert needs to be updated everywhere. This is the advantage to using something like the verisign public cert (root cert) as the installed cert on the client. The root certs usually last longer than the issued certs, but they will have to replaced eventually when they expire.
- When using Entrust certificates, obtained at https://www.entrust.com/get-support/ssl-certificate-support/root-certificate-downloads/ , how do we know that the certifactes are fed to the WSEMS configuration incorrectly?
- With the wrong configuration, WSEMS would error out rejecting the Entrust certificate:
- Non-fips Error code 20: Invalid certificate
- Fips: Error code 19: self signed certificate in certificate chain
- With the wrong configuration, WSEMS would error out rejecting the Entrust certificate:
- How to properly install Entrust certificate to be accessed by EMS?
- Public certificate needs to be downloaded and put in a directory that is accessible to the EMS. The path to be added to the cert chain field of the configuration.
- Even if its trusted it will always need to be installed on the EMS. If a certificate is self-signed, meaning it's non-trusted by default, OpenSSL would throw errors and compain. To solve this, it needs to be installed as a trusted server. If it's signed by a non-trusted CA, that CA's certificate needs to be installed as well.
- Once the certificates are obtained this if the block of the configuration we are interested in:
"certificates": {
"validate": true, //Not validated model is not recommended
"allow_self_signed": false, //Self signed model is not recommended, yet theoretically better than non-validated
"cert_chain": " " } //recommended, trusted - also the only way to work with a FIPS enabled EMS
- May use the SSL test tool (for example,https://www.ssllabs.com )to find all chains. For Entrust, both Entrust L1k and G2 need to be downloaded:
- Because cert_chain is an array type of field, the format to install the certificates paths, would be: "cert_chain": ["path1"], ["path2"]
- "cert_chain": ["C:\\ThingworxLocation\\MicroServerLocation\\locationofcertificates\\entrust_l1k.pem","C:\\ThingworxLocation\\MicroServerLocation\\locationofcertificates\\entrust_g2_ca.pem"]
