Can I concatenate certs and keys?

Situation: 2 unrelated domains (with respective subdomains) on the same physical multi-protocol server, same IP, same registrant.

With Apache, no problem: thanks to virtual hosts, I can serve different certificates according to which domain was requested.

But the mail servers I installed (OpenSMTPD + Dovecot) don’t support virtual hosts (AFAICT). So they can’t serve a different certificate depending on the domain name by which they were contacted.

Now, I know I could just tell certbot to request one single certificate for both domains and all their subdomains; but I’m afraid the result will be a set of huge files (just guessing here, I have no experience).

Since I like to keep my websites snappy, I’d like to maintain separate certificates/keys for the 2 domains. Then, only for the mail servers my idea would be:

cat domain1-fullchain.pem domain2-fullchain.pem > sum-fullchain.pem
cat domain1-privkey.pem domain2-privkey.pem > sum-privkey.pem

and let them use the summed fullchain and privkey for their TLS connections. The question is: will this work?

Thank you LetsEncrypt.org and community. :hand_splayed:

Both OpenSMTPD and Dovecot support SNI (if your mail clients do). So both can be configured with multiple certs.

In terms of copying multiple certs into a single file, no, I don’t believe that method would work ( I haven’t tested though).

If you only have the 2 domains, you could do as you suggest, and get certbot to obtain a cert for just those 2 domains ( or possibly those domains with mail., smtp, pop3 subdomains, depending what you actually use for your clients).

The other option I often use is a server name certificate, then use the server name as the “host name” for the client - and that works with a single cert, and no issue for clients that don’t support SNI.

1 Like

Concatenating the files would result in a file containing two certificates (or two keys). That won’t work.

You can ask Let’s Encrypt to issue you certificates which overlap. That is, domain A in one certificate, domain B in a second certificate, and then both A and B in a third certificate. There is no rule forbidding this, so long as you don’t exceed rate limits. The headache of keeping track of what’s used where would be left to you of course. But to be honest I suspect the A + B certificate would be fine on a web server, bigger by about the length of the extra names plus a little overhead.

1 Like

[quote="serverco, post:2, topic:23057"]
Both OpenSMTPD and Dovecot support SNI[/quote]
Good to know! Especially since it's not apparent from OpenSMPTD's documentation. For Dovecot, I must have used the wrong search terms: virtual hosts instead of SNI.

I would need a 3rd domain name, do I understand correctly? Or can I ask for a certificate for a local hostname as well?

Oh, too bad. That settles my first question, though.

Thanks for your replies. :thumbsup:

That depends how your server is set up. What is the "default" domain for your server / the IP ? You can always have one of your two existing domains, or you can set it to be a mail. subdomain of one of your existing domains.

1 Like

If you mean the name that turns up in a reverse DNS lookup, it doesn't have any. My VPS provider lets me assign one of my domain names to the server's fixed IP for reverse DNS lookups, but I think that's it.

Oh, and I can set the server's hostname, but that's only valid inside the server itself (AFAIK) or possibly within the provider's LAN as well. The mail servers do use that as a default if I don't specify anything else. I guess I can't request a certificate for that private name (I'd be happy to be mistaken on this point).

You can provide your server with any FQDN that you own, and get a certificate for it. You can use one of your domain names that you already use on it.

I was simply meaning that you use a single “server name” that your mail clients connect to, and you obtain a certificate for that “server name”.

1 Like

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