SSL import overwrites existing certificate with same CN
Article ID: 391241
Updated On:
Products
Issue/Introduction
dxcertgen -n Intermediate.cerFile importca
overwrites an existing certificate that share the same subject DN, CN being an common example seen in a certificate. At times, people may want to have both new and old certs co-exist.
Environment
Release: 14.1
Component: CA Directory
Cause
dxcertgen -n certifcaFile importca
is actually a utility that helps maintain the config/ssld/trusted.pem file to save administrators from having to manually manipulate the said file. Some of the common tasks including adding a new Certificate Authority base64 PEM data and replacing an expired or not Certificate Authority data from the file. As such, the overwriting an existing certificate that has the same Subject DN works by design.
Resolution
To support this co-existent use case, there are the right way of doing it and a workaround noted in the additional information section.
Allowing Certificates Authorities that Share the Same Subject DN
To allow a CA Directory Server to actually uses two valid certificates that have the same subject DN. One will need to maintain two separated "trusted.pem" files. As an example, before using the dxcertgen to import a certificate that contains a subject DN that exists in the config/ssld/trusted.pem file, we can make a copy of that file as config/ssld/trusted.old.pem. Then we do the import to update the config/ssld/trusted.pem to contain the new certificate.
Then to actually uses both Certificate Authority certificates, we are limited to have two different DSAs where one uses the updated.pem and the other uses the old trusted.pem.
As an example, if we have two DSAs dsa1 and dsa2. Then there will be dsa1.dxi and dsa2.dxi under the config/servers subdirectory. The dsa1.dxi can have the following snippet:
...
# ssld
source "../ssld/dsa1.dxc";
# multiwrite DISP recovery
...
while, dxa2.dxi has the following:
...
# ssld
source "../ssld/dsa2.dxc";
# multiwrite DISP recovery
...
then the config/ssld/dsa1.dxc can have the snippet as:
...
set ssl = {
...
# trusted root CA that signed DSA certificates
ca-file = "config/ssld/trusted.pem"
...
while config/ssld/dsa2.dxc has the following:
...
set ssl = {
...
# trusted root CA that signed DSA certificates
ca-file = "config/ssld/trusted.old.pem"
...
In other words, the ca-file setting wihin the set ssl determines the trusted Certificate Authority file that is being used. For more information regarding the set ssl, please see the following link:
set ssl Command -- Configure SSL
Additional Information
Temporary Workaround to Allow Certificates Authorities that Share the Same Subject DN
When CA Directory verifies whether a certificate is trusted worthy, it verifies the certificate against all the valid Certificate Authories that exist in the ca-file configured in the set ssl command. As such, an administrator can actually append a base64 PEM certificate to the trusted.pem file without using the dxcertgen importca command. After that, all the DSAs that uses the same ca-file will need to be stopped and re-started for it to take effect. Also, a ca-file that is manually manipulated in such a manner will break the usual dxgentcert importca behavior and will have to be managed manually until such a manipulation has been corrected.
To keep a CA Directory implementation in a supportable state, this workaround should be treated as a temporary exception. The reason for keeping both the old and new valid Certificate Authoritoes is naturally an exception and hence should be corrected as soon as possible. Leaving such an exception indefinitely is not advised.
Feedback
