© Marco Ferrante, CSITA - Università di Genova, 18/05/2005
Many people start to run a small Certification Authority to issue few certificates for SSL servers. Usually, they use directly OpenSSL tools.
As soon as the request for certificates grows, they realize that a more friendly PKI software is needed. EJBCA can be a good replacement.
This how-to is addressed to people who want to migrate their existing Certificate Authority from an OpenSSL-based software to EJBCA.
Instructions refer to version 3.07 of EJBCA.
C=IT DC=foo.bar CN=John Doe CN=John Doeemail@example.com employeeNumber=123456
When a certificate is stored or printed, DN is encoded, so RDNs acquire an order which depends on the cryptographic library used.
If you are using OpenSSL as a CA in a "classic" way, the order of RDN in subject name follows the order of fields in the policy section of OpenSSL configuration file, while issuer DN is verbatim copied from the issuer certificate.
Using default configuration file, OpenSSL produces certificates with DN ordered in X.500 style, where the most significant element leads (If your CA already uses a different order, you can skip this step). For example:
C=US, L=Area 51, O=Hanger 18, OU=X.500 Standards Designers, CN=John Doe
Thanks to Peter Guttman's X.509 Style Guide for the nice example
EJBCA internally handles DN as a set of RDN, and rearrange them only when a certificate file is produced. But EJBCA reorder both issuer and subject DN.
Using default configuration, EJBCA produces certficates with orders RDN as LDAP does (RFC 1779), where most significant element trails. For example:
CN=John Doe, OU=X.500 Standards Designers, O=Hanger 18, L=Area 51, C=US
As result, if you import a CA root certificate generated with OpenSSL, in which issuer and subject DN are encoded such as:
C=IT, O=University of Genoa, CN=My OpenSSL CA
the issuer in your certificates emitted using EJBCA will become:
CN=My OpenSSL CA, O=University of Genoa, C=IT
Note that above examples represent internal encoding; every software is free to print DN as prefers.
According to X.500, both forms should be acceptable and a order-insensitive way to compare DN is defined. Unfortunately, looking up in their keystore for trusted certificates, many libraries compare issuer DN in the same order they are encoded. This problem affects especially OpenSSL-based software, which computes hash on DN to speed up certificate search.
If your users have already loaded your root certificate in several programs (browser, email client, SSL/TLS server, ect...) probably they will experience several troubles with your new issued certificates.
You can avoid problems if your CA will be consistent and will use DNs in the same previous form in every certificate.
To change order in which DN will be encoded, edit se/anatom/ejbca/util/CertTools.java before deploy EJBCA and set
/** Change this if you want reverse order */ private static final String dNObjects = dNObjectsReverse;
This is a general option and cannot be set on per-CA basis. You cannot configure this option after EJBCA has been initialized because you will be unable to access to administration interface.
I hope this parameter can be configured by deployment script in future release of EJBCA.
openssl pkcs12 -export -out oldca.p12 -inkey <ca private key file> \ -in <ca certificate file> -name privateKey
ca.sh (or .cmd) importca <ca nick name> oldca.p12 <PKCS#12 password>
Now you can see the result in EJBCA administration interface. Sometimes, web interface require a while before "Basic Functions" displays imported CA, but it should be already listed by "Edit Certificate Authorities".
openssl pkcs12 -export -out oldsubca.p12 -inkey <sub ca private key file> \ -in <sub ca certificate file> -certfile <signer ca certificate file> -name privateKey
and importing it in the same way of root certificate.
migrate.sh <user name> <user password> <ca nick name> [ACTIVE|REVOKED] <user certificate file>
Using this syntax, defaults EMPTY end entity profile and ENDUSER certificate profile will be assigned to the user.
You can also specify profiles for user and certificate as last parameters, but pay attention to use profiles compatible each other as defined in your EJBCA configuration.