By using AWS re:Post, you agree to the Terms of Use

Error importing signed Private CA cert from external root


I set up a private subordinate CA, configured for an external root. I set up a basic CA structure using LibreSSL 2.8.3 (macOS 10.15.4) for the external CA with a self-signed root cert. When I exported a CSR from the AWS private CA, the Subject DN has its fields in a very unusual order:

C=US, O=Foobar, OU=AWS Subordinate CA, ST=New Dakota, CN=My AWS Subordinate CA, L=Sometown

When I use the openssl ca command to sign the CSR, the resulting certificate has the subject DN fields in the more usual order:

C=US, ST=New Dakota, L=Sometown, O=Foobar, OU=AWS Subordinate CA, CN=My AWS Subordinate CA

When I try to import the signed certificate I get an error:

The certificate subject contains a different subject than the CA certificate signing request.

Why does the Private CA generate the DN fields in that unusual order? And is there a way to fix this, either from the AWS side or the external CA side?

Edited by: PaulSuh on Apr 27, 2020 6:12 PM

1 Answer

To answer my own question:

Yes, there is a flag on the openssl ca command that will preserve the order of fields in the subject DN:

Normally the DN order of a certificate is the same as the order of the fields in the relevant policy section. When this option is set the order is the same as the request. This is largely for compatibility with the older IE enrollment control which would only accept certificates if their DNs match the order of the request. This is not needed for Xenroll.

So, this solves the immediate problem.

However, in the long run it would be better if the AWS Private CA put the subject DN fields in the more usual order of C=,ST=,O=,OU=,CN= This is supposed to represent a descent into an X.500 directory tree, and the order of C=,O=,OU=,ST=,CN=,L= is just bizarre.

Also note that the openssl ca man page specifically indicates that this option was created for a really old IE quirk, and is no longer needed. The OpenSSL/LibreSSL devs may remove this option and then we'd be stuck again. We could re-order the fields in the openssl.conf file, but this seems to be overkill for a single oddball case.

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions