Certs without CommonName not supported yet?

Client dev
1

Either I’m doing something wrong in my custom client (absolutely possible), or certificate generation without common names are not yet supported.

It’s been recommended to me on this forum to simply generate a CSR without a common name in the subject and the result ought to be a cert without a common name (see Multiple UCC/SAN (multiple subdomain) certs, single common name?). I’m guessing this has yet to be released even on staging, as that is where I’m seeing this behaviour. I haven’t tried on production as of yet.

My CSR generation code:

def generate_csr(key, domains):
    csr = x509.CertificateSigningRequestBuilder().subject_name(x509.Name([
        x509.NameAttribute(NameOID.COUNTRY_NAME, u"CA"),
        x509.NameAttribute(NameOID.STATE_OR_PROVINCE_NAME, u"BC"),
        x509.NameAttribute(NameOID.LOCALITY_NAME, u"Vancouver"),
        x509.NameAttribute(NameOID.ORGANIZATION_NAME, u"my-awesome-site.com"),
    #     x509.NameAttribute(NameOID.COMMON_NAME, u"my-awesome-site.com"),
    ])).add_extension(
        # Describe what sites we want this certificate for.
        x509.SubjectAlternativeName([x509.DNSName(domain) for domain in domains]),
        critical=False,
    ).sign(key, hashes.SHA256(), default_backend())

    csr_jose = jose.ComparableX509(OpenSSL.crypto.load_certificate_request(
        OpenSSL.crypto.FILETYPE_PEM,
        csr.public_bytes(serialization.Encoding.PEM)))

    return csr, csr_jose
2

I believe this is the case. AFAIK Boulder always puts one of the SANs into the CN if none is provided. @jsha I think you know the most of the backstory about this & the compatibility issues with CN-less certificates. Can you reply with a summary?

EDIT: It seems that Boulder doesn't always do this, but can be configured not to based on the RA's forceCNFromSAN config parameter. I suspect we have this set to true in prod and staging presently but don't know the story on why or whether it will change soon.

1 Like
3

That’s correct, we don’t yet support it. The flag isn’t turned on because we decided to go with another approach. Long story short, we think we need a BR update to do this right. There is an upcoming ballot.

2 Likes
4

What is a BR update?

So, I won't be able to achieve what I'm looking to do then, not just yet. That's what you're telling me. Boo, poor me.

5

Sorry, was typing on my phone and using shorthand. The CA/Browser Forum publishes Baseline Requirements (BRs) that we have to adhere to. Those need to be updated.

6

Unfortunate. Will have to rethink/redesign/refactor that element of my integration. Thanks for the prompt replies.

1 Like
7

A common solution to this problem is to define one hostname that you control that appears in all your CNs. E.g. tls.automattic.com shows up in the CN of all their certificates.

We definitely have been wanting to issue CN-free since the beginning, so glad to know you are interested in using it once it’s ready!

8

For some reason, I thought it had to be tls1.automattic.com, tls2.automattic.com, etc - ie. a unique subdomain as the common name per certificate?

Also, there's the issue with rate limiting with this method (20 certs/week * 100 domains/cert = 2000 domains covered). I certainly don't expect to run into this in the initial stages, but surely others have. I assume they requested a rate limit increase to get around any issues?

Edit: I see what you mean (with the tls.automattic.com example) - Wordpress.com uses it as the common name for their customers' CNAMEd blog domains, bunching them all together into SAN certs. But they have a non-LE wildcard cert for non-CNAMEd wordpress blogs.

9

Yep, you’ve got it exactly right.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.