S/MIME certificates with step-ca: problem

[jwildeboer]

Hello all.

I am trying to understand the various RFCs, CA/Browser S/MIME WG basic requirements, I have collected a bunch of S/MIME certs from other providers to abstract all of that into using step-ca to create working S/MIME certificates.

BUT. I run into a few problems. The biggest one being the Subject CN. So I'd like to ask: Am I doing something wrong or is step-ca a bit too strict?

Here's the thing. According to the RFCs etc, for modern S/MIME certs the use of emailAddress in the subject is deprecated, all email addresses must be SANs. The CN in the subject is typically used for the full name of the recipient (there are a lot more rules, but this is the one I am struggling with).

Step-ca just won't do it and always refuses with cannot parse cn domain \"Nathaniel Smith\".

Here's what I did:

• create new provisioner called smime step ca provisioner add smime --create --type=JWK --x509-min-dur 168h --x509-default-dur 8760h
• Add template to the provisioner that adds the needed OID for organisation-provided, multipurpose cert amongst other things

{
    "subject": {
        "Organization": {{ toJson .Organization }},
        "organizationalUnit": {{ toJson .OrganizationalUnit }},
        "commonName": {{ toJson .Subject.CommonName }}
    },
    "basicConstraints": {
		"isCA": false
    },
    "extensions": [
        {"id": "2.5.29.32", "value": {{ asn1Seq (asn1Seq (asn1Enc "oid:2.23.140.1.5.2.2")) | toJson }}}
    ],
    "sans": {{ toJson .SANs }},
    "extKeyUsage": ["emailProtection", "clientAuth"],
    "keyUsage": ["keyEncipherment", "digitalSignature", "contentCommitment"]
}

• Add template data to set O and OU

{
  "Organization": "JHW HomeLab",
  "OrganizationalUnit": "S/MIME"
}

This should be sufficient for minimal S/MIME certs. And it happily works when I use the email address as subject/CN:

step ca certificate "[email protected]" --san "[email protected]" --san "[email protected]" --san "[email protected]" nsmith.crt nsmith.key --provisioner smime

But it fails when I use the name as CN:

step ca certificate "Nathaniel Smith" --san "[email protected]" --san "[email protected]" --san "[email protected]" nsmith.crt nsmith.key --provisioner smime
✔ Provisioner: smime (JWK) [kid: na5k[...]VA]
Please enter the password to decrypt the provisioner key: 
✔ CA: https://ca.at.home:4443
error creating certificate
Re-run with STEPDEBUG=1 for more info.

And step-ca tells me:

time="2025-08-11T06:44:16Z" level=error duration=61.197591ms duration-ns=61197591 error="cannot parse cn domain \"Nathaniel Smith\"" [...]

So, the question is ...

Is there a way to configure step-ca to accept the full name as CN? I also tried adding surnameand givenName to the subject, but AFAICS that is not supported and can only be done if I encode them directly as OID.

Bonus question: How do I set the authority policy to get step-ca to accept any email address? It seems I have to add every single domain I own with a step ca policy authority x509 allow email @domain.tld because even when I remove them all, I still get a The request was forbidden by the certificate authority: email name "[email protected]" not allowed for every domain I try.

[hslatman]

Hey @jwildeboer,

The error originates from our issuance policy engine. You mention it at the end of the message, but it's not showing the full policy configured, so I can't say for sure what the policy is that you're using.

For the Common Name, it's currently a bit of a special case: https://smallstep.com/docs/step-ca/policies/#subject-common-name. If you only need "Nathaniel Smith", you should add that as an allowed CN, explicitly. It's pretty limited intentionally, so that we don't get too much configuration sprawl here, but I suppose we're open for suggestions. There's in fact logic in the CA to disable validation of the CN, but there's currently no knob exposed for that.

If your policy has rules for a different kind than email, and no active rules for email, all emails will be forbidden. The idea is that when you're explicitly allowing e.g. dns, we'll block any email, unless there are email rules too.

[jwildeboer]

Thank you, that helps a lot in understanding. I analysed a bunch of S/MIME certs from several commercial CAs to understand how they work with CN in the subject. The "CN is a flexible identifier and not an email address" seems to be the most common choice. (I changed the names, obviously:

Telekom Business Security S/MIME
Subject: C=DE, O=Company GmbH, CN=Albert Smith, GN=Albert, SN=Smith, [email protected], organizationIdentifier=NTRDE-HRB111111

GlobalSign GCC R6 SMIME CA 2023
Subject: C=CH, ST=Zürich, L=Zürich, organizationIdentifier=VATCH-CHE-111.111.1111, O=ACompany ag, CN=Albert Lastname

GEANT Personal CA 4
Subject: postalCode=199 99, O=České v Praze, street=Jugoslávských partyzánů 1111, ST=Praha, Hlavní město, C=CZ, CN=Peter Surname, [email protected]

So it seems that for legacy, backwards compatibility reasons 2 out of 3 still add an emailAddress to the subject but no-one puts it in the CN.

So that would be something worth thinking about. But I happily admit it is maybe specific to S/MIME certs only?

WRT policy. Understood! After I completely emptied the policy from

OLD

{
   "x509": {
      "allow": {
         "dns": [
            "step"
         ],
         "ips": [
            "192.168.1.0/24",
            "172.16.1.0/16"
         ]
      },
      "deny": {}
   },
   "ssh": {
      "host": {
         "allow": {},
         "deny": {}
      },
      "user": {
         "allow": {},
         "deny": {}
      }
   }
}

to

NEW

{
   "x509": {
      "allow": {},
      "deny": {}
   },
   "ssh": {
      "host": {
         "allow": {},
         "deny": {}
      },
      "user": {
         "allow": {},
         "deny": {}
      }
   }
}

I can generate S/MIME certs for all domains. And no CN checks when I use the full name.

$ step ca certificate "Test User" --san "[email protected]" tuser.crt tuser.key --provisioner smime
✔ Provisioner: smime (JWK) [kid: na5k[...]OVA]
Please enter the password to decrypt the provisioner key: 
✔ Certificate: tuser.crt
✔ Private Key: tuser.key
$ openssl x509 -in tuser.crt  -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            14:fe:b6:5c:c8:4b:c9:69:38:2d:7f:49:5a:4c:b9:ef
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=JHW Homelab CA, CN=JHW Homelab CA Intermediate CA
        Validity
            Not Before: Aug 12 16:21:05 2025 GMT
            Not After : Aug 12 16:22:05 2026 GMT
        Subject: C=DE, O=JHW, OU=S/MIME, CN=Test User
[...]

I guess I will solve this pragmatically by setting up a second step-ca container for "normal" certs with the ip/dns restrictions I want for my homelab and using the first instance ONLY for S/MIME.

But If you people could discuss relaxing the CN requirement for (maybe only) S/MIME certs that would be grand!

Thank you for the help and explanations!