Certbot picks up wrong CN from the SAN list while renewing/creating cert

mack · July 17, 2023, 5:48am

Hi,
i am using certbot --certonly utility to renew / issue certs. I have mutiple SAN list which consists around 8 names.
command: certbot certonly kid=xxx key=xxx --server "https://xxx/" --config /cert/cert.conf --cert-name "x1.com" -d "x1.com" --key-type "rsa" --rsa-key-size 2048 -d "x2.com,x3.com,x4.com,x5.com,x6.com,x7.com,x8.com,x9.com,x9.com" --webroot -w /cert/certbot-certs

when i run this command multiple times certificate common name is changed and randomly picked up from SAN list. ("x2.com,x3.com,x4.com,x5.com,x6.com,x7.com,x8.com,x9.com,x9.com")

I need certificate common name to be same as specified by first -d option (-d "x1.com")

is this possible ?

webprofusion · July 17, 2023, 6:48am

This doesn't appear to be an option in certbot, but I think you can do it if you provide your own CSR:

github.com/certbot/certbot

Consider whether to add a flag to control whether the CSR contains a Subject CN

opened 12:56AM - 24 Jan 23 UTC

alexzorin

area: policy priority: unplanned

Related to #9542 and [this community thread](https://community.letsencrypt.org/t…/connection-between-ios-9-support-and-subject-common-name-or-x509v3-subject-alternative-name-critical/191619/31?u=_az), there's an argument for adding a flag to control whether Certbot includes a Subject CN on its CSR. Currently, Certbot does not do it, which is a best practice, and that [has been the justification in the past](https://github.com/certbot/certbot/issues/6463#issuecomment-435151087). Let's Encrypt forcibly includes a Subject CN on the certificate, so no compatibility problems crop up in practice. However, they have indicated that they will stop doing so in future. As pointed out by our users in numerous issues, some other CAs like BuyPass, do respect the CSR's choice of Subject CN, and this has compatibility consequences for TLS clients. It feels a bit backwards to include a flag for a deprecated behavior this late in the game, but I think we could consider whether doing so will have any future-proofing benefit for our users (like `--preferred-chain` did).

It can be done in some other ACME clients.

Osiris · July 17, 2023, 7:26am

I believe Let's Encrypt uses the first SAN entry as CN. They did change this behaviour some time ago though, but I thought they reversed that decision? In a post on the Certbot Github repo @jsha said:

Update on the community thread: at Let's Encrypt we're going back to the old behavior for now (first SAN from CSR promoted to Subject CN instead of alphabetically-first SAN). But we still plan to push towards no-Subject-CN issuance for almost everyone, and eventually for everyone.

Maybe LE changed something again?

MikeMcQ · July 17, 2023, 10:46am

What certificate authority are you using?

mack · July 18, 2023, 4:12am

Digicert

schoen · July 18, 2023, 5:15am

It might be tough to find out Digicert's issuance policies from the Let's Encrypt Community Forum.

I think this is an interesting thing to understand and document, including about other CAs, but it's unlikely that people here will know the answer offhand. There are Certbot developers here who can tell you about Certbot behavior, but the content of the issued cert is ultimately determined by the issuer, not the requester.

orangepizza · July 18, 2023, 5:27am

from certbot source code certbot doesn't fill CN and end CSR without any CN to ACME server

github.com

certbot/certbot/blob/c31d3a2cfd1d55b9027e0932cd3dc373bc43b514/acme/acme/crypto_util.py#L225


      
                  try:
                      client_ssl.do_handshake()
                      client_ssl.shutdown()
                  except SSL.Error as error:
                      raise errors.Error(error)
              cert = client_ssl.get_peer_certificate()
              assert cert # Appease mypy. We would have crashed out by now if there was no certificate.
              return cert
          
          
          def make_csr(private_key_pem: bytes, domains: Optional[Union[Set[str], List[str]]] = None,
                       must_staple: bool = False,
                       ipaddrs: Optional[List[Union[ipaddress.IPv4Address, ipaddress.IPv6Address]]] = None
                       ) -> bytes:
              """Generate a CSR containing domains or IPs as subjectAltNames.
          
              :param buffer private_key_pem: Private key, in PEM PKCS#8 format.
              :param list domains: List of DNS names to include in subjectAltNames of CSR.
              :param bool must_staple: Whether to include the TLS Feature extension (aka
                  OCSP Must Staple: https://tools.ietf.org/html/rfc7633).
              :param list ipaddrs: List of IPaddress(type ipaddress.IPv4Address or ipaddress.IPv6Address)

Osiris · July 18, 2023, 6:09am

Correct. That's why @webprofusion suggested to generate and provide your own CSR with CN. Although I don't recommend Certbot using a separate CSR, as that behaviour is very different from other Certbot modes of operation and e.g. cannot be renewed automatically IIRC.

petercooperjr · July 18, 2023, 12:04pm

It may be easier to fix whatever system is requiring a particular CN, than to try to coerce certbot and Digicert to giving you that CN. The industry is moving toward trying to get rid of having any domain name in the CN entirely.

rg305 · July 18, 2023, 7:50pm

I have to ask....
For this specific purpose, do you really need a cert that covers multiple names?
[if you request a cert with only one name, then the CN is guaranteed]

system · August 17, 2023, 7:51pm

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