When issuing a Wildcard certificate, how do you do it?
Would you put the wildcard into the common name or into the Subject Alternative Name?
certbot certonly -d *.domain.tld -d domain.tld
or
certbot certonly -d domain.tld -d *.domain.tld
As far as i know, both works. But i've seen both kinds, when i checked out crt.sh.
Doesn't matter, the common name is deprecated and shouldn't be used anyway. All browsers wouldn't care, only very old legacy TLS clients could possibly give some trouble, ignoring the SAN.
In terms of specifically how Let's Encrypt does things: If you use the modern "tlsserver" or "shortlived" profile, then it won't have a CN at all. If you use the default "classic" profile, then, if I recall correctly, it will use the CN that the ACME client put in the CN field of its CSR, or (if the ACME client didn't include one) then just pick one of the SAN names that's less than 64 chars to use as the CN (or leave the CN empty if all the names are too long).
Your example commands are for certbot; I think certbot used to put the first domain name you specified as the CN in the CSR it used. But any recent version I believe don't include it.
But it shouldn't matter, so why are you interested in the CN? We keep hearing about these obscure systems that need it to exist or be a particular value, but details are scarce, so any data you can give about what systems might need it could be helpful to the community as the industry moves toward finally getting rid of it completely.
This may be the case for HTTPS, but what about SMTP? I mostly use Let's Encrypt Certificates for Mailservers.
As far as i know, the Common Name is not deprecated in terms of SMTP.
Also: if you run a mailserver, you have to expect that an old piece of software tries to send you a message.
By the way: there are tons of mailservers on the internet, which only work with RSA certificates. ECDSA = error.
Why wouldn't it be?
Problem mostly is that TLS is usually horribly broken on mail servers to begin with.
RFC 2818, published in May 2000, deprecates the use of the Common Name (CN) field in HTTPS certificates for subject name verification.
Because RFC 2818 is HTTP specific, not SMTP.
I cannot find any RFC equivalent for SMTP. So i assume, that using the common name is still valid and necessary for SMTP.
Anyone correct me, if i am wrong!
I think you're looking for RFC 7817, section 3. It says that systems MAY use the CN, but are required to recognize SAN entries as well (and so a certificate that only puts the hostnames in the SAN should work with SMTP software that complies with that RFC).
There's also RFC 9525 for all TLS server identity, which says that "it is no longer valid to use the commonName RDN, known as CN-ID" and "The Common Name RDN MUST NOT be used to identify a service."
Now, certainly there is plenty of old SMTP software out there. Many systems won't care about validating hostname at all by default (under the theory that if the STARTTLS wasn't there even unencrypted would be acceptable). Again, I haven't seen a good survey of the ecosystem of what happens in practice, and it'd be helpful if someone wanted to collect data to quantify just how much CN reliance there is out there.
That's a rather wordy way of saying that too many outdated and poorly maintained servers are still in service on the internet. I know that Proofpoint had that problem at one time, because it is the entire reason I have certbot on a mailserver. I'm fairly certain that is no longer an issue, but I still have that certbot managing one RSA certificate for now.
¯\(ツ)/¯