Mounting /etc/letsencrypt/ on a Azure File share (CIFS)

I’am experimenting to use Lets Encrypt in Load Balanced configuration.

To obtain a certificate I can use
certbot certonly --webroot -w /var/www/lets-encrypt/ -d

/var/www/lets-encrypt/ would be in this case a smb/cifs share mounted on multiple machine’s behind a layer 4 load balancer.

The next challenge is to make the certificate accessible to all the servers. For this I would like to mount /etc/letsencrypt/ as a smb/cifs file share. This seem to cause some trouble. I think it is because certbot uses symbolic links and smb/cifs seem to have some trouble with it.

When running certbot certonly --webroot -w /var/www/lets-encrypt/ -d and having /etc/letsencrypt/ mounted as a smb/cifs share I get a error message. The following relevant information can de found in the log file
2017-10-01 14:58:55, directory /etc/letsencrypt/archive.
2017-10-01 14:58:55, directory /etc/letsencrypt/live.
2017-10-01 14:58:55, directory /etc/letsencrypt/archive/ and live directory /etc/letsencrypt/live/ created.
2017-10-01 14:58:55,490:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/certbot”, line 11, in
load_entry_point(‘certbot==0.17.0’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python2.7/dist-packages/certbot/”, line 753, in main
return config.func(config, plugins)
File “/usr/lib/python2.7/dist-packages/certbot/”, line 692, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File “/usr/lib/python2.7/dist-packages/certbot/”, line 82, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File “/usr/lib/python2.7/dist-packages/certbot/”, line 375, in obtain_and_enroll_certificate
File “/usr/lib/python2.7/dist-packages/certbot/”, line 1013, in new_lineage
OSError: [Errno 95] Operation not supported

I’am wondering if other people have a working solution for sharing Let’s Encrypt certificates with multiple webservers.

You need a network file system that supports symbolic links.

You can add mfsymlinks to your CIFS mount options on each server to enable virtual symlink support for Windows-backed CIFS shares. (These symlinks will work on other Linux systems with this mount option enabled, and on Macs, but they will appear as files when viewed from Windows computers.)

You could also use a Unix-backed CIFS share with the CIFS Unix extensions, or NFS, or anything else that supports symbolic links.

I cannot speak as to how Certbot will behave if two instances running on different machines try to access e.g. cli.ini concurrently, however.

Instead of mounting /etc/letsencrypt in a filesystem without symbolic links, you could also make something like /etc/letsencrypt/export and then (assuming that you only have one certificate) run cp /etc/letsencrypt/live/* /etc/letsencrypt/export after each certificate issuance or renewal, perhaps via Certbot’s --post-hook option. Then you could mount /etc/letsencrypt/export for all of the machines.

In this case I think the sensible thing would be to have one master machine running Certbot, which gets and renews the certificates on behalf of all of the machines. If you have shared /var/www/lets-encrypt so that they all serve that same directory, one machine should be able to satisfy the challenge regardless of which instance the certificate authority hits during the verification. There’s no benefit to issuing duplicative certificates for each load balancer in this case if you specifically intended to share the resulting certificate and private keys once they’ve been issued.

Bear in mind that your SMB mount might be unencrypted and so private keys might be exposed to the LAN, allowing someone with LAN access to perform an HTTPS MITM attack against visitors to the site.

1 Like

Thank you for the input, I will look what will work best.

Regarding security. This setup is hosted on Azure, so I’am trying to use the service from Azure. De SMB share is Azure File storage which uses SMB 3.0 and is protected by a long key. I will have to find out if the SMB link is encrypted.

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