DorianIs there by now something like #letsencrypt but for s/mime? And anticipating the answer: why not?
Jan Wildeboer π·
TIL (Today I learned) about RFC9495 https://datatracker.ietf.org/doc/rfc9495/ that extends RFC8659 by adding a new CAA property in DNS called "issuemail" that defines wich CA(s) (Certification Authorities) are allowed to create S/MIME eMail certificates for a domain. And if you don't use S/MIME, you should set it to ";" which means that no CA is allowed to do that.
So I added
CAA 0 issuemail ";"
to the dns of my domains until my CA (Certificate Authority) can produce S/MIME certificates.
RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses
The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension.
Happily sending around signed and encrypted emails that use S/MIME certificates that I created myself on my own CA. And as my mail server (that I also run myself) has DKIM, DMARC, SPF set up correctly, that also works. Nice!
So now that I have my own s/mime certificate generated and installed, here's the SHA256 fingerprint:
19dae1a388af5c91e3dc53d89e3efdaef3f24878b9d37f809463ee801f3eae25
Should you get an email from me, it will be signed and with this fingerprint you can verify that indeed it was me who sent it.
I know almost no one will ever actually do this verification, but it is reassuring to me that you can :)
I have brain dumped the process at https://codeberg.org/jwildeboer/gists/src/branch/main/2025/20250803SmimeCertStepCA.md and will work on an extended version as blog post in the next few days. Big shoutout to @ben again for getting the process up and running in the first place!
If you want to get a signed email from me to see what happens in your mail client, DM me an email address and I will send a s/mime signed email to you :)
6/6
If I understand the whole s/mime stuff correctly, I can send you a signed email and your mail client should be able to extract my public key from that. You reply with a signed mail, I can extract your public key. Now we can send encrypted emails :) Your mail client/operating system won't trust my certificate as it is signed by my CA (Certificate Authority), but it should still work.
5/6
After some help from @ben and some swearing about PKCS12 (add a password when you package the .p12 file so that Android and iOS will be able to import it) and Keychain on MacOS, itβs working. S/mime signed and encrypted mails with certificates from my own CA.
4/6
If you want to play with free S/MIME certs for e-mail signing and encryption, https://acme.castle.cloud does that letsencrypt style with ACME and certbot :) Made and operated by the Centre TecnolΓ²gic de Telecomunicacions de Catalunya (CTTC). A non-profit research institution based in Castelldefels (Barcelona).
3/6
It shouldn't be complicated (famous last words ;). Just a x509 certificate with `keyUsage = contentCommitment, digitalSignature, keyEncipherment` and `extendedKeyUsage = emailProtection` and of course the `commonName` and `emailAddress` set ...
UPDATE: first little mystery solved. https://social.wildeboer.net/@jwildeboer/114964253139353077
2/6
Jan Wildeboer π·:krulorange: (@jwildeboer@social.wildeboer.net)
Attached: 1 image TIL (Today I Learned): While openssl uses the identifier `nonRepudiation` for the 2nd bit in the keyUsage field in x509 certificates, the correct identifier since at least 2008 is `contentCommitment` according to the ITU TR and RFCs and so that is what step-ca uses. A bit (pun intended) confusing, but now I know :) https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3 #NerdTalk
Seems nobody has documented how to use step-ca to create certificates for S/MIME (e-mail)? OK. I guess I will have to go down that road unprepared and write it down as a gist or blog entry myself :) (Will take a few days, depending on when I find enough time to go through everything)
1/6