freeipa

#9846 RFE: Support for better S/MIME certificates
Opened by orion. Modified

Open
Close Issue

Request for enhancement

We are trying to leverage our IPA infrastructure to issue S/MIME certificate for email aliases that we have in use at the company. I created a userSMIMECert profile using the instructions here:

https://access.redhat.com/solutions/6982899

But I'm running into this constraint:

invalid 'csr': DN commonName does not match user's login

Which I don't think is appropriate for S/MIME certs - the commonName is generally the "Full Name" of the user.

According to Alexander Bokovoy this is hard-coded in the IPA certificate issuance validation before we pass the request to Dogtag CA:

        elif principal_type == USER:
            # check user name
            if cn != principal.username:
                raise errors.ValidationError(
                    name='csr',
                    error=_("DN commonName does not match user's login")
                )
            # check email address
            #

which is very limiting.

But the real show stopper is that the issued certificate does not contain the email address in the subject.

Needs further investigation, but it seems reasonable to expand this to accept as CN:
- Full Name;
- email;
- kerberos principal.

This started as a freeipa-users question in https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/6E5TNS2JEBYL44OXAQT7WGIPAZFMEIBB/

What does alias mean in this context? Is it a shared account? What use case are you trying to solve?

It's an email distribution group. We want to be able the send and receive encrypted email with that group.

What value are you trying to use for the principal name? What does the user entry look like?

Ideally, I would prefer to not have a user associated with the certificate at all - and just have some admin principal have the ability to issue these arbitrary S/MIME certs - that's closer to what I've been able to do with AD CA. But at the moment the user/principal is "it_help" 

  User login: it_help
  First name: IT
  Last name: Help
  Home directory: /home/it_help
  Login shell: /sbin/nologin
  Principal name: it_help@NWRA.COM
  Principal alias: it_help@NWRA.COM
  Email address: it_help@nwra.com
  UID: 14004
  GID: 14004
  Certificate: MIID8jCCAtqgAwIBAgIEP/oAHjANBgkqhkiG9w0BAQsFADAzMREwDwYDVQQKDAhOV1JBLkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTI1MDgyOTE3MjI0OVoXDTI3MDgzMDE3MjI0OVowJTERMA8GA1UECgwITldSQS5DT00xEDAOBgNVBAMMB2l0X2hlbHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDkJCTHitvcBxycHh7N34cuGdpP+1hyw5O7QqTenRPgYAHcTr5S1V/TkV/YaOh1apkgQF4UfES/VZ9jzicSyktD+i5f7Mt/+YRnbUPAEwoNs4mYo2e0BzYBamFjQeCzcZrCKvsQpuVF2IBqg2zXIGACZefU68Hh6leqYZ2eWJipFDlQoOEdSewgEWqeh8mCImpfL17PufLSosNfF0hzXuKUvZj/dvIcO0+sNyYjhMq6BRlvhlURo9+fi0PfvQLWghBzKyboxG1RmRoucBsev593I8d6hWAtKuf2RS8EJ9OVLNaSFnbcPS+W80aQE55V5sW/NX8ngLYPoGJ+P8wbQn7AgMBAAGjggEaMIIBFjAfBgNVHSMEGDAWgBRJr/Opqx2kIY/fbYPKINHSOrCzVjA6BggrBgEFBQcBAQQuMCwwKgYIKwYBBQUHMAGGHmh0dHA6Ly9pcGEtY2EubndyYS5jb20vY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwcwYDVR0fBGwwajBooDCgLoYsaHR0cDovL2lwYS1jYS5ud3JhLmNvbS9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFOigXEAIQQPkTPIAhciM5G9nxjUrMA0GCSqGSIb3DQEBCwUAA4IBAQBFqoDSAvFhSu9SWl43N0pXJvM9qyrT3REzf7GFnGJQwXJFTnrKw8PaHeL0FeqjUi3CFXgxPFmc1MxUFwSMV3zkq+DaVtT8nBJX7RemNWxQ5hQF4OwFuDY+Ske+d1jjAHlWn0lfogPdw6nErB1FnvqwMPciZMUQgWP8x14toApzK924WHyH7fISryeDJSVPXV32RkXWUUqCaFlxOBy5FnLvl+0GQCBrf0JwqAGgL0Jk/+T2cyIQMv4Z5kiEKZKMdrajEdZMAgQWvKpTissJDcAgm8YmFFslUKWPmfQSz5eUn2BZgbvonXDoMRQQRg2bV6uAG+xPsvTZO/j+UrwQ6Yor
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

But as the edited first message now states - the real show stopper is that the email address is not added to the subject.

Hi!
I've modified the solution to include email SAN into the request - the certificate gets SAN as expected:

[root@ipa9 smime]# openssl x509 -text -in testuserCert.pem 
Certificate:
    Data:
        Issuer: O=TEST.LOCAL, CN=Certificate Authority
        Validity
            Not Before: Sep  4 19:06:32 2025 GMT
            Not After : Sep 28 14:22:03 2025 GMT
        Subject: O=TEST.LOCAL, CN=testuser
...
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: 
                E-mail Protection
...
            X509v3 Subject Alternative Name: 
                email:testuser@test.local

Will this work for you?
Edited by kororland

@kororland that does work better - the email address show up. Thanks!

Still would be nice issue certs with full names and without having to create a user for it.

@orion In IPA framework, there is an idea that we're not supposed to be issuing unvalidated certificates - we need to validate the extension data in them against some internally verifiable entries, so I don't see creating user certificates without any user object to work off it if we are speaking for IPA. It is not the case for the standalone dogtag, for example, where you are free to define your own policy on issuing certificates.

Full names in subject, however, are debatable, it is very possible to do. Is there anything specifically requiring only full name in subject's CN?

Hmm, I suppose we could create a sub-ordinate dogtag CA.

In the context of S/MIME certs, at least in Thunderbird when you click on the "signed" icon you will see the subject displayed as "Signed by: SUBJECT" and we generally expect that to be the Full Name of the person, not their username. It would be similar for signing documents. So it's not a technical requirement per se, but it is what people expect to see.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.