Friday, I read this article talking about a CA giving SSL/TLS certificates for free. Youhou !

There will be Let’s Encrypt soon. And I am waiting forward. But they will probably have hard times in the beginning. So why not using this Chinese CA while waiting ?

This is precisely for that reason that I did the upgrade.

I have to admit something: their website is Chinese ! Slow and probably a bit buggy, or has some troubles through the Great Firewall of China.

As there was mails to receive, I deactivated the anti-spam by this time, to avoid having a bad configured Chinese server trapped in my bad guys list. It is not a joke or racism : their mailserver had apparently a few bad settings.

But I finally got a certificate ! And so did I activate TLS on all my websites. It is actually reuse of my previous configuration, but use of encryption is now enforced.

Certificate safety

In order to improve my safety, I created a system users group and they are the only ones with reading access to certificates and private key.

Members of this group: _smtpd, _smtpq, spamd, www.
Is it useful ? I don’t know. But i cost so few (you still need to move fingers on the keyboard !). So why not doing so ?


As written in yesterday article, I set a generic tls configuration by placing it in an include file. One has to be lazy enough. It means efficiency and easier maintenance.

Between today and yesterday articles, and the manual - take care of the version, you may have a pretty good idea of the possibilities offered by the new OpenBSD web server.


listen on *   tls  port 443
listen on ::  tls  port 443

tls     key	        "/etc/ssl/private/server.key"
tls     certificate	"/etc/ssl/server.crt"
tls     protocols	"TLSv1.1,TLSv1.2"
tls     ciphers   	"AES256+EECDH:AES256+EDH"

The certificate comes with a whole chain of trust. So I placed them all in one file, which is the server.crt as indicated above.

cat 3_user.crt 2_issuer.crt 1_intermediate.crt root.crt >> server.crt

I cannot figure out yet how to use sophisticated tls options like dhe and ecdhe. I also use TLSv1 et 2. Because there might be some visitors with not up-to-date softwares. But I don’t allow use of TLSv1.0 and SSL. I still have an amazing rating on SSLlabs.


The two listen lines allow to warrant listenning on both inet and inet6 protocols. When writing this article, I used egress. Weirdly, it did not listen on inet6. Same if using *.

Ciphers’ choice is complicated. So I choosed to get back to the ssl conf’ in the ssl links (french).

Thanks to OpenBSD dev’ for secured by default.


server "" {
	alias ""

	include "/etc/httpd.tls"

	root "/pelican"

	location "/bibliotheque/" { block return 301 "" }
	location "/biblib/"     { block return 301 "" }

	location "/drafts/*"    { directory auto index }
	location "/downloads/*" { directory auto index }

	location "*/feed/" { directory index atom.xml }

	location match "/2012/02/27/*"  { block return 301 "" }

server "" {
	listen on *        port 80
	listen on ::       port 80
	block return 301 "https://$SERVER_NAME$REQUEST_URI"

I cannot use the server match pattern directive either. Nor that hsts. It would have been cool to set a massive redirection of all http websites to their https counterparts.

I was thinking something like:

server match "*" {
	listen on *        port 80
	listen on ::       port 80
	block return 301 "https://$SERVER_NAME$REQUEST_URI"

I will see. Reyk, the developer, or other persons might publish more detailed and powerful configurations. In that case, I will update this article after having adapted my own.



# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = required

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/ can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
ssl_cert= </etc/ssl/seul.crt
ssl_key = </etc/ssl/private/server.key

# How often to regenerate the SSL parameters file. Generation is quite CPU
# intensive operation. The value is in hours, 0 disables regeneration
# entirely.
ssl_parameters_regenerate = 168 hours

ssl_dh_parameters_length = 1024

# SSL protocols to use
ssl_protocols = !SSlv2 !SSLv3

# SSL ciphers to use
ssl_cipher_list = AES256+EECDH:AES256+EDH
ssl_prefer_server_ciphers = yes

To be sure of the configuration, go to the Dovecot documentation. Sadly, ssl parameters are really low detailed !

As the certificates are being read before dropping daemon privileges, this one does not need to be member of the tls user group.


I don’t use the whole chain of trust for SMTP server. Just the final certificate, saved in the seul.crt (single in French).

Smtpd configuration is really simple:

pki key                "/etc/ssl/private/server.key"
pki certificate        "/etc/ssl/seul.crt"
pki dhparams           "/etc/mail/certs/dh4096.pem"

I use dhparams options. It is dead simple to do, just like to create a new key:

openssl dhparam -out dh4096.pem -outform PEM -2 4096


Spamd now listen with TLS ! But one does not set the certificates files to use in spamd.conf but in its init command !

So, in rc.conf.local, you have to set this :

spamd_flags="-v -G 25:4:864 -C /etc/ssl/seul.crt -K /etc/ssl/private/server.key"

Certificate is with -C and -K for the key. -G indicate the greylisting times.


Finally, one can publish TLSA records. Actually, as we use the same certificate everywhere, it will be the same record as well. The whole chain of trust or the single cert give the same result.

In fact, only Spamd and Smtpd must share the certificate. And as Postfix, very popular SMTP server, recognize it now, it is good !

But it is not yet recognized by any web browser. You need a plugin.

TLSA records are described here.

openssl x509 -noout -fingerprint -sha256 < seul.crt | tr -d :

So, in my DNS zone file :     IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )      IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )     IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )            IN TLSA 3 0 1 ( 69169B52DBC4C5E2875E1DD9F573A15C7B607566E41395C3C22EE0D141522302 )