This file can be deleted, after the certificate is signed (which is done in the next step). This will create the file cert-file, which contains the certificate-signing-request. keystore test.jks -storepass confidential \ ![]() If you create a new one, there is no need to specify the SAN-extension, since it will not be exported into the request and this version of the certificate will be overwritten, when the signed certificate is reimported: We are reusing the already created certificate here. import -alias ca-root -file ca-cert -nopromptĬreate A Certificate-Signing-Request For Your Certificat keystore truststore.jks -storepass confidential \ To distribute the root-certificate, so that your Java-clients can trust all certificates, that are signed by your CA, you have to import the root-certificate into a truststore and make that truststore available to your Java-clients: ca-key, the private key of your CA with the password extraconfidentialīe sure to protect ca-key and its password, because anyone who has access to both of them, can sign certificates in the name of your CA!.ca-cert, the root-certificate of your CA.keyout ca-key -out ca-cert -days 365 -passout pass:extraconfidential new -x509 -subj "/C=DE/ST=Niedersachsen/L=Juist/O=juplo/OU=security/CN=Root-CA" \ We are using openssl to create the root-certificate of our private CA: Recipe To Create A Private CA With Self-Signed Multi-Domain Certificates Create And Distribute The Root-Certificate Of The CA If you just need a working solution for your development setup, you may skip the explanation and just download the scripts, that combine the presented steps. In the following sections, I will walk you through a solution to circumvent this pitfall. This default behavior is very annoying, if you just want to run your own private CA, to authenticate all your services to each other. Hence, all entries in a SAN-extension are removed by default during signing. If a client could write arbitrary additional domains in the SAN-extension of his certificate-signing-request, he could fool the CA into signing a certificate for any domain. This removal of the SAN-extension is not a bug, but a feature.Ī CA has to be in control, which domains and IP’s it signes certificates for. (One may think, that you just have to specify the export of the SAN-extension into the certificate-signing-request – which is not exported by default – but the SAN will still be lost after signing the extended request…) ![]() This way, only the root-certificate of that private CA has to be distributed.Ĭlients, that know the root-certificate of the private CA will automatically trust all certificates, that are signed by that CA.īut unfortunatly, if you sign your certificate, the SAN-extension vanishes: the signed certificate is only valid for the CN. The common solution in this situation is, to create a private CA, that can sign newly created certificates. This is feasible, if you just want to authenticate and encrypt one point-2-point communication.īut if more clients and/or servers have to be authenticated to each other, updating and distributing the truststore will soon become hell. The problem is, that it is not signed and will not be trusted, unless you publicize it explicitly through a truststore. The certificate is also valid for this additionally specified domains and IP’s. …you should see a section like the following one: #1: ObjectId: 2.5.29.17 Criticality=false If you list the content of the newly created keystore with… keytool -list -v -keystore test.jks dname "CN=test,OU=security,O=juplo,L=Juist,ST=Niedersachsen,C=DE" \ keystore test.jks -storepass confidential -keypass confidential \ The following example shows the syntax for the keytool-command, that comes with the JDK and is frequently used by Java-programmers to create certificates: One can simply specify the additional domains (or IP’s) when creating a certificate. Multi-Domain certificates are implemented as a certificate-extension called Subject Alternative Name (SAN). Subject Alternative Name (SAN) And Self-Signed Certificates
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |