I was trying to create a CSR using the acme.crypto_util module and found that the CSR is being created without a Subject Name.
For my environment I need to be able to create certificates with a CN, but as far as I saw in the acme.crypto_util.make_csr(), it just leaving the whole Subject Name empty.
Why not allow customization of the subject_name? Even maybe just take the first SAN as the CN.
Am I missing something?
Thanks
Because it's deprecated for years now? Why keep supporting deprecated items?
That said, I believe, currently, Let's Encrypt puts one of the SAN in the CN.. For now..
In the link I attached you can see that the subject_name is empty, as long as the CN.
Its not taking one of the SANs into the CN.
Certbot != Let's Encrypt..
Yes, creating a CSR without a CN, and whether the CA you send it to puts something into a CN in its leaf certificates, are different things, though sometimes the CA uses the CSR to influence its picks.
Can you be really clear on what tools you're using that require a CN (and why, if possible), and if they need them in the CSR, the leaf certificate, or both? It may be that you need to switch clients and/or switch CAs, depending on your needs. But anything that's expecting a CN is very old and (at least somewhat) broken.
@petercooperjr Thank you for your response.
There are some programs in our environment that requires a certificate with a CN to authorize some traffic.
We also have our custom CA in this environment.
At the final step, I need a leaf certificate with a CN.
Right now, we are using the python package simple_acme_dns to create a csr and sign it.
This package is using certbot.acme.crypto_util to generate the csr.
And in the link I provided earlier, we can see that the function is leaving the CN field empty.
I opened an Issue in simple_acme_dns github repo, and got answered that I should reach to this community for help because their package is using yours.
@Osiris Hi, I might have some misunderstandings about those terms.
Certbot is a software for signing Let's Encrypt certificates?
I was in certbot's GitHub repo and was gonna open an Issue, and got a link to this community from their repo before opening a new Issue.
So that was a bit confusing for me.
Certbot is one of many pieces of software called an "ACME client". Those clients can "talk" to an "ACME server". Let's Encrypt is one of a few CAs out there that run an ACME server. There are also other CAs offering free certificates from their ACME server.
So even while Certbot doesn't add a CN to the CSR, the signing CA (like Let's Encrypt) can choose to add a CN anyway.
Well, strictly speaking it's using acme.crypto_util. While the acme library is coded by the Certbot team and it's part of the Certbot repository, speaking in terms of Python packages, it's separate from the certbot package.
And it does,usually, as noted in Classic profile docs
That's… weird, but okay, fine.
Are you talking about leaf certificates from your custom CA? Are you using ACME to request certificates from your custom CA?
I think that the better place may be the acme or certbot python teams, though it's certainly a common bit of confusion since Let's Encrypt is the most common (and default) CA that certbot connects to.
There are also other CAs that offer paid certificates from their ACME server. ACME (which certbot implements) is just a way to automate the requesting of certificates from a CA, it really isn't related to the cost of them. (I know Osiris knows this, just trying to make it clear for everyone.)
True, there's even a CA out there that let's you pay for free certificates if you happen to have money in the account that's coupled to the ACME account used 
Or something like that.. 
(ssl.com I believe..)
Yes, I am using ACME to request a certificate from our custom CA.
We have our custom ACME server in our environment.
So my systems need to get a certificate with a CN included.
So if I got it right, we have to configure our CA to take the first SAN for example as a CN?
Like the Classic profile of Let's Encrypt?
Yes, that's probably be the easiest approach. If you're in control of both the client and server sides, another approach would be to switch to a different client that puts the desired CN into the CSR and have the CA use the CN provided there instead. But regardless you'd need to have your CA get the CN to put in from somewhere if you want to force the certificates to have it.
I don't want to force anything.
I just want the ability to issue certificates with a CN.
Either custom CN taken by the CSR or just by the CA taking the first SAN as CN.
As you said, I do have control of both the client and server sides.
And in order to change the client side, we have to change all of our programs.
Because the package simple_acme_dns is using acme.crypto_util.
And they are both not allowing to set a CN.
So the easiest way for us to do it is to modify our CA configuration?
Or should it be the ACME server configuration?
Should know to which team of us to reach.
I would think it'd be a part of your CA configuration. But configuring a CA is getting a bit out of my expertise.
It would probably be very easy to simply patch Certbot to include the first hostname as the CN..
Yeah, I know that.
That's why I reached out to their GitHub repo in the first place.
And they directed me to this community 
.
I was gonna suggest a PR to allow users to create a CSR with a CN.
So it seems like my next steps should be a PR to certbot, or modify our ACME Server or CA.
And anyway, according to your explanation, it seems like this topic is not related to this community.
Am I right about those?
You're probably not the first to suggest that. And the Certbot team probably declined.
Your best bet is to fork Certbot, patch it, and use your fork.
Thank you for that.
That's probably right.
But if I will patch this package on my local environment, when I'll want to get a new released version it will cause some headache and extra work from us.
Extra work? Sure.. Much extra work? I doubt that.. It's not a difficult patch
diff --git a/acme/src/acme/crypto_util.py b/acme/src/acme/crypto_util.py
index c20c49c7d..db765c687 100644
--- a/acme/src/acme/crypto_util.py
+++ b/acme/src/acme/crypto_util.py
@@ -304,7 +304,9 @@ def make_csr(
builder = (
x509.CertificateSigningRequestBuilder()
- .subject_name(x509.Name([]))
+ .subject_name(x509.Name([
+ x509.NameAttribute(NameOID.COMMON_NAME, domains[0]),
+ ]))
.add_extension(
x509.SubjectAlternativeName(
[x509.DNSName(d) for d in domains]
(Note that if no domain is specified but just one or more IP address, this patch will raise an exception.. Although currently Certbot doesn't support IP addresses, so if the acme library is only used with Certbot, it shouldn't matter much.. Also.. Not tested.. Might not work at all )
That said, the issue I linked above was closed automatically without an actual decision written down.. Maybe the Certbot team is open for the suggestion.