Using Let's Encrypt for virtual mail hosts

Server
1

How would I request a certificate for my virtual mailbox domains? Or my actual mailhost, which doesn’t run any web services on that domain?

In this case I have a single host, host.domain.com, which accepts mail for domain.com, domain1.com, domain2.com, domain3.com, and domain4.com, as well as serves content through nginx at vhost.domain.com, vhost1.domain.com, vhost2.domain.com, and vhost3.domain.com.

I know I need certificates for vhost*.domain.com ( or a *.domain.com wildcard!) but for the SSL/TLS mail side, what about host.domain.com, or all of the domainX.com which have nothing in DNS aside from MX records?

1 Like
2

just include host.domain.com as any of the other vhost*.domain.com domains so that it is covered by the cert. Then config the mail system to use the cert.

3

So I just need a single cert, for host.domain.com (the actual physical system)? This doesn’t seem correct. Can you be more clear please?

4

The certs are domain name centric. Whatever domain name the client uses to access the service, that domain name has to be covered by the cert.

5

What about SMTP transfers between domains? Do those not use the domain name associated with the address, but trust the MX records and use the mail host’s certificate?

The vhosts all need their own certs, which is what I understood. Just don’t know enough about SSL and SMTP/IMAP/etc services.

6

Message transfers via SMTP MX servers does not support SSL/TLS far as I know.

7

Ok, so next question, how do I manually generate a certificate for my host that I use for the mail host, as it doesn’t do any port 80/443 serving.

This is more of a lets encrypt client thing.

8

I think you use standalone mode. But will have to make sure port 443 is open for it to work. Essentially in standalone mode the client runs it’s own web server instance for doing the domain validation. I think.

9

Many systems ignore the certificates used for STARTTLS because a bunch of servers have them set up wrong…

10

the LE cert is restricted

X509v3 Extended Key Usage: 
    TLS Web Server Authentication, TLS Web Client Authentication
2 Likes
11

Am I correct in assuming we won’t have these restrictions in the future so we can use the LE certs for mail services and DANE?

12

you can make LE work with DANE now, see. just for 443.

13

What about mail services?

14
  1. this restriction is flagged as "non-critical".
  2. the OID 1.3.6.1.5.5.7.3.1 for this restriction is usually translated to humans as "ServerAuth" (Server Authentication). Don't know where the "web" comes in here, possibly from browser programmers.

So: don't worry. Will work for any other TLS services (SMTP/POP3/IMAP/FTP/...) as well.

5 Likes
15

Not that most mail services complain about my self signed cert, aside from a client or two (but certainly not enough of them).

16

WEB != HTTP(s) | HTML

Web in this context refers to the “internet”. Which contains many types of services, including email.

17

this restriction is flagged as "non-critical".

what this really means to X.509 is "you're not required to reject this just because you don't understand it."

the OID 1.3.6.1.5.5.7.3.11 for this restriction is usually translated to humans as "ServerAuth" (Server Authentication). Don't know where the "web" comes in here, possibly from browser programmers.

RFC 5280 4.2.1.12 says:

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

So the name says one thing and the comments say something slightly else. Can't imagine how anybody could misunderstand that.

2 Likes