Install postfix MTA cert

Hello

Wondering if anyone has a guide for using letsencrypt with postfix. Specific MTA has no open web port, only SMTP.

Currently with the ‘staging’ command, i see letsencrypt trying to reach the web port.

MTA:

letsencrypt certonly --staging --standalone -d xxxx.xxxx.com

FW:

denied tcp 2600:1F14:AC6:4F10:505A:1249:9E33:EDAE(43984) -> 240x:xxxx:xxxx:1::1x(443), 1 packet
denied tcp 2600:1F16:185:3210:FA10:3CAA:9DF7:9CE9(59754) -> 240x:xxxx:xxxx:1::1x(443), 1 packet
denied tcp 2A05:D014:FBE:3D10:162F:8FCE:FC0A:A96C(47784) -> 240x:xxxx:xxxx:1::1x(443), 1 packet

Malz

Let’s Encrypt must obtain proof that whoever is asking for a certificate truly controls the name they want on the certificate.

Ten methods are permitted for use by CAs on the public Internet, each may choose to offer a different selection from those ten. Let’s Encrypt automates three of those methods. To obtain a Let’s Encrypt certificate you will need to be able to perform one of these three methods. Two of them need a service, either port 80 or port 443 usually offered by a Web server. The third option is DNS proof, to perform this you must be able to add/modify DNS records for the name you need a certificate for.

1 Like

Hi @malz

Your firewall should allow port 443 through. The standalone command spins up a temporary (python based) web server to answer the challenge.

After the challenge is complete no one will be able to connect on port 443 (as the web server is turned off)

This is a good solution for mail servers that do not have port 80 or 443 open

You were almost there just a small correction to firewall rules.

Note: Let’s Encrypt does not publish IP addresses so you cannot whitelist a certain IP range.

I have written an article about this sort of testing however as you have not provided a domain I can’t recommend more. Tutorial - Testing Mail Protocols with SSL/TLS

In terms of cipher support i recommend you look at this: https://www.sidorenko.io/post/2014/02/secure-ssl-configuration-for-apache-postfix-dovecot/

Andrei

standalone Y N
Uses a “standalone” webserver to obtain a certificate.
Requires port 80 or 443 to be available. This is useful on
systems with no webserver, or when direct integration with
the local webserver is not supported or not desired.
http-01 (80) or tls-sni-01 (443)

Thanks for the post tialaramex.

If you use the DNS route, what is involved ? I certainly can turn up any records required. Obviously the MTA has an A & AAAA presently.

Thanks for the post ahaw021, very good.

I can’t say i endorse an approach where security is determined by a hosts application turning up and turn down a service.

I would certainly, at an minimum, whitelist the prefixes of your boxes reaching out, where i see roughly a handful.

Appreciate the additional links you’ve included. Will have a read.

Malz

For DNS challenges what happens is that Let’s Encrypt picks a random number each time it needs proof of control, and you (or software on your behalf) need to construct a DNS TXT record which proves you knew the random number and your ACME account key.

Certbot can automate this process with some common DNS APIs, and the well known third party script https://acme.sh/ can do this with way more APIs out there and is easily extensible if you know how to write shell scripts to modify DNS records for your system. Certbot is also happy to manually tell you the DNS records that should be created, but this is a pretty awful choice because somebody (you?) has to go do the manual steps every few months or your certificates can’t be renewed.

1 Like

Most people (I guess over 95%) who are trying to get publicly-trusted certificates are trying to get them on web servers, and so they're able to use the existing web server in conjunction with an ACME client to complete the challenges. Both port 80 and port 443 validations are supported and the ACME client can create a file (in the former case) or make a web server configuration change (in the latter case) to let the existing web server pass the challenge. The "standalone" method of creating an ephemeral service exists primarily for those few people—like you—who are trying to get a certificate for some other purpose.

In turn, the reasons for using these ports have to do with the industry-approved validation methods that @tialaramex mentioned.

It's quite possible that the DNS method will be simpler and more practical in your case. If you search for "ip address whitelist" or similar terms on this forum, you'll see that whitelisting the source IP addresses for the other methods is explicitly not supported (the challenge tests can come from any IP address and the IP addresses used are subject to change without any notice), so if you would be inclined to do that, we would even more strongly recommend the DNS method as an alternative.

Have completed the DNS path successfully. Its actually not that complex!

Certificates working perfecting on two postfix MTAs. DANE updated perfectly.

I do have some ideas to automate this, now i understand the required operations.

Malz

1 Like

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