On su, 12 huhti 2020, Fredrik Arneving via FreeIPA-users wrote:

Hi Rob,

Thank you for answering. Though it would probably make the signing pass it's not my preferred solution. A lot of this is new to me but here's my thinking. Please feel free to add links and suggestions.

According to RFC3739, section "3.1.1 Issuer", the issuer field SHALL (yes, it's capitalized in the RFC) identify the organization issuing the certificate. Further, the distinguished name of the issuer should be specified using a subset of

• domainComponent;
• countryName;
• stateOrProvinceName;
• organizationName;
• localityName; and
• serialNumber

Shuld I make the organizationName optional or supplied it will only leave the countryName as a match and I don't think that qualifies as "appropriate subset".

Looking at section "4.1.2.4 Issuer" in RFC5280 (replacing RFC3280) they talk about "DirectoryString" with a choice of encodings where PRINTABLESTRING and UTF8STRING are the two conforming to the RFC with a couple of exceptions for older environments.

When I read this I draw the conclusion that a freeIPA server added as a sub-CA to an existing PKI-infrastructure can run into a CA which expects the "organizationName" to be encoded in either PRINTABLESTRING of UTF8STRING. To make it as flexible as possible it should be possible to configure this in some config file (that would be preferred from digging into the code).

I don't get many hits when googling this problem which gives me a bad feeling that I am missing something obvious. Any hints would be greatly appreciated.

Should I not find a solution for this I have to go with the CA-less installation and write all my certs manually which would be a lot more work than to have the freeipa server doing it.

When you ask FreeIPA installer to generate a CSR for signing by an external CA, the actual CSR is created by NSS library with the help of Dogtag's pkispawn utility which configures an actual request submitted into NSS database used for the IPA CA storage.

So, pkispawn ends up running 'certutil' command with corresponding parameters to generate a certificate request. Certutil will do parsing of the provided certificate's subject and will end up using organization name from there.

The logic for choosing encoding for organization name is actually the same as for any DirectoryString element and it follows RFC 4630. I'm going to show it here in all its C glory because it is short and easy in lib/certdb/alg1485.c, ParseRFC1485AVA function:

if (vt == SEC_ASN1_DS) { /* RFC 4630: choose PrintableString or UTF8String */ if (IsPrintable((unsigned char*)valBuf, valLen)) vt = SEC_ASN1_PRINTABLE_STRING; else vt = SEC_ASN1_UTF8_STRING; }

In other words, if your organizationName value can be represented in ASCII (isPrintable), it will be represented in ASCII. If not, then UTF-8 will be used.

Historically, this place was known for debates in certificate-related communities. You can see the bug https://bugzilla.mozilla.org/show_bug.cgi?id=329067 which led to the current logic in NSS.

Neither FreeIPA nor Dogtag have control over this behavior. If you consider that NSS violates the logic described in RFC 4630, please raise this with NSS development team at bugzilla.mozilla.org.

On su, 12 huhti 2020, Fredrik Arneving via FreeIPA-users wrote:

Hi Alexander,

Thank you for explaining this to me. Next question:

Given that my "oranizationName" is given on the command line as an argument to the --ca-subject and --subject-base flags, can you help me figure out if it is possible to give these arguments in some way that the nss library would intrepret as non-printable and hence set the "vt" value as "SEC_ASN1_UTF8_STRING?

NSS accepts #-hex-encoded values, so if you are able to encode your O=... value in advance, express it in hex and specify with

O=#aabbccddeeff1122334455...

But I am not sure FreeIPA will accept that at all, not tried that myself.

Any hints on how to avoid rebuilding my existing PKI infrastructure would be nice.

You can create an intermediate manual CA that actually will handle IPA CA signing request in the form it is provided.

Hi Fraser,

Thanks for putting time into this matter.

In the back of my head I've started the re-design of my private LAN to avoid this problem altogether. I have enough trouble learning the basics of certificate handling so first things first...

I'll probably get back to this thread with more "ordinary" questions once my actual work starts.

Thanks for now. /Fredrik