Tag Archives: certificate

Let's Encrypt Certificate for SMTP with STARTTLS

TLS Encryption

Let's Encrypt provides an easy way to get free certificates not only for web servers, but also for email servers like Postfix.

The way Let's Encrypt usually works requires you to setup a web server. Let's Encrypt sends you a challenge, and you have to prove ownership of the domain by providing a response to that challenge. You do this by placing the response in a certain URL on your web server:
http://www.yourserver.com/.well-known/acme-challenge/FgedPYS65N3HfwmM7IWY2...

That way you prove that you are the owner of the domain "yourserver.com". But there is another even easier way to prove ownership of a domain: DNS. You place the response in a specific TXT record of your domain: _acme-challenge.www.yourserver.com

  • You can use your domain hosting service (GoDaddy, Whois, etc.) to create a new TXT record.
  • The "certbot" command line client does all the rest in just one call.
  • Under Debian 9 and 10, "certbot" is part of the official package repository.
  • You can run certbot on any Linux client. You don't have to run it on the email server.

Example

In this example the public hostname of your mail server is mx.yourserver.com. Therefore you have to create a TXT record called _acme-challenge.mx.yourserver.com . The value of the TXT record is in the output of certbot.

# certbot certonly --manual --preferred-challenges dns -d mx.yourserver.com
 
Saving debug log to /var/log/letsencrypt/letsencrypt.log 
Plugins selected: Authenticator manual, Installer None 
Obtaining a new certificate 
Performing the following challenges: 
dns-01 challenge for mx.yourserver.com 
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
NOTE: The IP of this machine will be publicly logged as having requested this 
certificate. If you're running certbot in manual mode on a machine that is not 
your server, please ensure you're okay with that. 
 
Are you OK with your IP being logged? 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(Y)es/(N)o: Y 
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Please deploy a DNS TXT record under the name 
_acme-challenge.mx.yourserver.com with the following value: 
 
1A4RACHEISTBLUTWURST_egTVadkeiieikeieisfkfk
 
Before continuing, verify the record is deployed. 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Press Enter to Continue 
Waiting for verification... 
Cleaning up challenges 
 
IMPORTANT NOTES: 
 - Congratulations! Your certificate and chain have been saved at: 
   /etc/letsencrypt/live/mx.yourdomain.com/fullchain.pem 
   Your key file has been saved at: 
   /etc/letsencrypt/live/mx.yourdomain.com/privkey.pem 
   Your cert will expire on 2020-02-15. To obtain a new or tweaked 
   version of this certificate in the future, simply run certbot 
   again. To non-interactively renew *all* of your certificates, run 
   "certbot renew" 
 - If you like Certbot, please consider supporting our work by: 
 
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate 
   Donating to EFF:                    https://eff.org/donate-le
Share

Certificate Authorities (CA) in Google Chrome / Chromium and Firefox on Linux

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is the list of all root CAs included in Firefox along with their fingerprints:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Builtin root CAs are hardcoded in /usr/lib/firefox/libnssckbi.so . You can see a list of all CAs in Firefox preferences (advanced settings).

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d $HOME/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:
https://www.chromium.org/Home/chromium-security/root-ca-policy

In Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so which is part of the package "libnss3". You should therefore update this package as soon as there is an update available to keep your builtin CA list up-to-date.

CAs that are not builtin and that you installed manually are stored in your home directory:
certutil -d sql:$HOME/.pki/nssdb -L

Important things to note:

  • The security of SSL encrypted websites (https://...) depends on the root CA which is used to sign the website certificate. These CAs are stored locally on your device in different locations based on the browser you are using.
  • There are 2 kinds of CAs:
    1. Builtin CAs that ship with your browser or linux installation. They are stored in shared object files. There is probably no easy way to edit this list unless you change the source files and recompile the package. Nevertheless in both browsers you can remove all trust from a builtin certificate which is basically the same as deleting it.
    2. Manually added CAs are stored in your home directory. You can easily edit that list within the settings of the browser or on the command line.
  • Both Firefox and Chromium / Google Chrome use NSS certificate databases to store manually added CAs that are not builtin. But they use different directories. Maybe you could use symbolic links to point both directories to the same database. That way both browsers would be using the same manual CA list.Currently Firefox uses by default the legacy dbm database version (cert8.db, key3.db) and Chromium / Google Chrome uses by default the new SQLite database version (cert9.db, key4.db). There seems to be an environment variable NSS_DEFAULT_DB_TYPE that makes Firefox use the new SQLite database version as well (s. https://wiki.mozilla.org/NSS_Shared_DB_Howto).
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".
Share

Security check for postfix (STARTTLS connection)

$ openssl s_client -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 -starttls smtp -verify 3 -verify_return_error -debug -CApath /etc/ssl/certs -connect 1.2.3.4:25

"-tls1_2" forces the TLSv1.2 protocol. Make sure protocol and cipher list match.

"-verify 3" enables server certificate verification and sets the length of the certificate chain. In this case there are 3 certificates in the certificate chain, including the root CA. Make sure the public root CA certificate is in the "-CApath" directory. "-verify_return_error" enforces the certificate verification to succeed.

The "-cipher" option specifies the list of ciphers to be transferred to the server. The server then decides which of these ciphers to use. As we only give one cipher, we force the postfix server to only use this one. If the server does not support this cipher, openssl will return with an error.

If everything goes well, you will see a long output from the server (including the protocol and cipher from your openssl command line options) and something like "Verify return code: 0 (ok)". Quit the connection with the postfix server by typing "quit" and hit return.

Share

Create a self-signed certificate for ip address

openssl.conf:

[req]
default_bits = 4096
distinguished_name = req_distinguished_name
req_extensions = v3_ca
x509_extensions = v3_ca

[req_distinguished_name]
countryName = Country
countryName_default = GB
countryName_min = 2
countryName_max = 2
localityName = Locality
localityName_default = London
organizationName = Organization
organizationName_default = Roland Ltd.
organizationalUnitName = OU
organizationalUnitName_default = Roland-OU
commonName = CN
commonName_default = 192.168.12.122
commonName_max = 64
emailAddress = Email
emailAddress_default = postmaster@local.example
emailAddress_max = 40

[v3_ca]
extendedKeyUsage=serverAuth
subjectAltName=IP:192.168.12.122

# openssl req -newkey rsa -config openssl.conf -days 32 -x509 -out new.cert -keyout new.key

Add the option "-nodes" to avoid having to type in a password for the private key. You will need this e.g. if you use the certificate for Apache and do not want to type in the private key password every time you restart your webserver.

You also might want to add "-sha512" to make the signature algorithm use the SHA512 digest. Otherwise a reasonable default will be used. For Ubuntu 14.04 (OpenSSL 1.0.1f) the default has already been set to SHA256.

Share