To trust our Root CA, we first have to export it.Įvery browser allows to view the certificate, e.g. Sharing credit card information or other personal details could be dodgy in such a scenario. In this case we're communicating in a secure way, but do not know if the server (and its providers) can be trusted or not. However, it's already using encrypted traffic as every HTTPS connection will use TLS. ThingWorx can now be called via It's not yet trusted by the client - so it shows as potentially unsafe, and for me it shows in German as well *sorry* Restart Tomcat to consider the new configuration. I'm using a connector on port 443 (as it's the default HTTPS port): In ThingWorx, configure the /conf/server.xml as e.g.
Keystore explorer make jks password#
Tomcat - the private key password should never be shared with a source you do not trust! The keystore password will be shared with e.g. It's highly recommended and (hopefully) obvious that passwords for the other private keys should be different and that the password for the keystore should be completely different as well. Save the keystore via File > Save As and set a password - this time for the keystore itself.Īs Tomcat has a restriction the password for the keystore must be the password for the private key of the server specific certificate. If this is not the case - the certificates and establishing trust will not work!
Notice the expiry date - the higher up the chain, the sooner the expiry date. Make it the same as the Common Name (CN) above.Īs before, confirm everything with OK, enter an alias and a password for the private key part.Īll certificates should now show with their corresponding properties in the certificate list: In addition to this, a Subject Alternative Name must be defined - otherwise the latest Chrome versions consider the certificate as invalid.Ĭlick on Add Extensions and the + sign, choose Subject Alternative Name.Īdd a new name with the + sign. If the servername does not match exactly, the certificates and establishing trust will not work! 300 days.įill out the Name again - this time it's important to actually use the public servername, so that browsers can match the server identity with its name in the browser's address bar. In the list right-click the Intermediate CA and Sign > Sign New Key PairĮnsure the validity period is less than for the Root CA, e.g. The new Intermediate CA will now show up in the list of certificates. To reflect this, a Basic Constraint must be added via Add Extensions.Ĭonfirm with OK, set the alias (or leave the default) and set the password for the private key part. 301 days.įill out the Name again - this time as Intermediate Certificate.Ī Intermediate Certificate is a Certification Authority (CA) in itself. Use the RSA algorithm with a key size of 4096 again.Įnsure the validity period is less than for the Root CA, e.g. In the list right-click the Root CA and Sign > Sign New Key Pair This is a common approach as - in case the signing CA for the server specific certificate gets corrupted, not all of the created certificates are affected, but only the ones signed by the corrupted CA. The intermediate CA is signed by the Root CA and used to sign the server specific certificate. The new Root CA will now show up in the list of certificates. Only the Common Name is required - usually I never use the Email field, as I want to avoid receiving more spam than necessary.Ĭlick OK and enter an alias for the Root CA (leave the default).Ī new password needs to be set for the private key part of the certificate. Leave the other defaults and fill out the Name (addressbook icon). It's important that all subsequent certificates have a lower validity period than the original signer. Use the RSA algorithm with a key size of 4096. Via Tools > Generate Key Pair create a new key-pair. Open the KeyStore Explorer and create a new jks KeyStore To learn more about the theory behind trust and encryption, see also Trust & Encryption - Theory In this example I'll be using the KeyStore Explorer, a graphical tool for managing keystores.
Keystore explorer make jks how to#
There are already some examples available on how to do this via command line using a self-signed certificate, e.g. In this blog post I'm covering the pratical aspects of setting up a Chain of Trust and configure ThingWorx to use it.
0 kommentar(er)
