X509v3 extensions for MTAs

It appears that certain MUA clients (e.g. Samsung S8) are starting to get picky about certificates that have X509v3 extensions that don’t include email and general encipherment.

So letsencrypt sets these fields:

    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Basic Constraints: critical
            CA:FALSE

Whereas for email + web serving (or just encrypted “media”) we probably need something like this:

     X509v3 extensions:
        Netscape Cert Type:
            SSL Client, SSL Server, S/MIME
        X509v3 Key Usage:
            Digital Signature, Key Encipherment, Data Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection

Could this be added to future proof the strictness that is finally creeping into email TLS conversations?

It seems a trivial change, that increases overall utility.

PS. The relevant openssl config looking like this:

[v3_req]
nsCertType = client, server, email
keyUsage = keyEncipherment, dataEncipherment, digitalSignature
extendedKeyUsage = serverAuth, clientAuth, emailProtection
subjectAltName = @alt_names

It’s unclear to me why MUA would require the emailProtection EKU for TLS server certificates. Is there some kind of documentation that mentions this requirement?

S/MIME doesn’t happen on the TLS layer and uses different certificates, issued for individual email addresses. Let’s Encrypt doesn’t issue S/MIME certificates, so if you’d try to use one that way, that would indeed not work. I’m not aware of any plans for S/MIME certificates on Let’s Encrypt’s end.

1 Like

The specific use cases are MTA <-> MTA SSL communications and MTA <-> imap server actions. As for documentation, all I can suggest is the openssl docs. The config shown produced a working certificate that covers web and email transactions. The S/MIME thing just falls out with that config.

So here is the complete thing, create config.cnf:

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
x509_extensions     = v3_req
prompt              = no

[ req_distinguished_name ]
countryName         = GB
stateOrProvinceName = Worcestershire
localityName        = Worcester
organizationName    = TubbyLand
commonName          = public.tubby.org

[v3_req]
nsCertType          = client, server, email
keyUsage            = keyEncipherment, dataEncipherment, digitalSignature
extendedKeyUsage    = serverAuth, clientAuth, emailProtection
subjectAltName      = @alt_names

[ alt_names ]
DNS.1 = www.tubby.org
DNS.2 = tubby.org
DNS.3 = smtp.tubby.org
DNS.4 = imap.tubby.org
DNS.5 = public.tubby.org 

Generate a self-signed certificate:

openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:4096 -keyout server.key -out server.crt -config config.cnf -extensions 'v3_req'

Check the resultant certificate with:

openssl x509 -in server.crt -noout -text

Suddenly a Samsung S8 starts talking to the imap server. But only by replacing a Comodo certificate with this selfsigned one.

I still don’t understand how this relates to S/MIME.

When you use S/MIME, you obtain a certificate from a trusted CA which includes your email address (verified by the CA), and then configure your mail client to use this certificate (and its key), for example to sign messages. When you send an email signed with your key, all the magic happens in the email header and body. From the SMTP server’s perspective, it’s just yet another message, and when you talk to your SMTP server via TLS, the SMTP server uses its server certificate and your S/MIME certificate isn’t involved at all. Similarly, when you retrieve an email from your IMAP server, and that email happens to be an S/MIME message, that doesn’t affect the TLS certificate used by your IMAP server, it’s just a property of the message. A certificate that would cover both does not make a whole lot of sense in this context.

1 Like

Even if Samsung has arbitrarily decided to insist on wacky nonsense, that doesn’t make wacky nonsense a good idea, it makes Samsung an outlier and it hurts the Web PKI for everybody else.

    Netscape Cert Type:
        SSL Client, SSL Server, S/MIME

… is hopelessly obsolete. Nothing should still be relying on this obsolete crap in 2017. Certainly not a brand new phone.

Requiring the Key Usage: Data Encipherment is not obsolete but very, very weird. In theory what it means is that you propose to use the keys to directly do public key crypto, which is very slow and cumbersome, instead of using it only to do key agreement and then use much faster and better symmetric crypto to actually send messages. Nobody does this. It’s in the standard in case anybody ever needs it, but requiring it will usually mean somebody has no clue what they’re doing and thought “Yeah, encipherment, that sounds like something I need”.

If you can work out what the S8 actually requires exactly, that might be worth re-reporting here, but most likely the main target needs to be Samsung who’ve apparently included random requirements that make no sense.

Hmm…

This may be based on a misunderstanding of the documentation. I suspect this is what is really wanted:

[v3_req]
nsCertType          = client, server
keyUsage            = keyEncipherment, digitalSignature
extendedKeyUsage    = serverAuth, clientAuth, emailProtection

which yields this:

X509v3 extensions:
    Netscape Cert Type: 
        SSL Client, SSL Server
    X509v3 Key Usage: 
        Digital Signature, Key Encipherment
    X509v3 Extended Key Usage: 
        TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection

which is what is specifically wanted.

It is the E-mail protection part that is the extra bit we are after.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.