letsencrypt certificate expired #3429

vikasrawal · 2023-07-16T16:54:04Z

vikasrawal
Jul 16, 2023

When I update my ssl certificate using the following command, I get the message that the certificate is not yet due for renewal.
"You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry."

docker run --rm -it \
  -v "${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/" \
  -v "${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/" \
  -p 80:80 \
  certbot/certbot certonly --standalone -d mymailhost.com

But docker-mailserver picks up the older ssl certificate, and I get an error that the certificate has expired. I am unable to poll the imap server because of this. Also https://www.sslchecker.com/sslchecker shows:

Resolves to mymailhost.com
Expiration date May 24, 2023
Vendor signed Yes
Hostname Matches
Key length 256
Server type NA

I will greatly appreciate if somebody could help me resolve this problem. My mail server has suddenly become unusable because of this.

polarathene · 2023-07-18T23:26:27Z

polarathene
Jul 18, 2023
Maintainer

You should probably share how you're mounting the certs to DMS container as well? Is it the same volume mount as you've got in your docker run snippet above? I am guessing you're following the Certbot LetsEncrypt advice in our docs?

If it's using an old certificate, maybe look at what the container itself sees. It's possible that it's not aware of the updated file contents internally. If the file has changed, then probably what needs to happen is Postfix/Dovecot is restarted, this should happen by default unless you're using LDAP.

If you are using LDAP you'll have to manually restart the DMS service (docker compose up --force-recreate) and it should work then. In future that may not be required, just requires some additional work to our change detector support.

0 replies

vikasrawal · 2023-07-23T04:50:05Z

vikasrawal
Jul 23, 2023
Author

Thanks for your kind reply, and apologies for the delay on my side. There was some other trouble because of which I was unable to work on the server. Am back at it now.

You should probably share how you're mounting the certs to DMS container as well?

This is how the volumes are mounted in docker-compose.yml ```yml volumes: - ./docker-data/certbot/certs/:/etc/letsencrypt - ./docker-data/dms/mail-data/:/var/mail/ - ./docker-data/dms/mail-state/:/var/mail-state/ - ./docker-data/dms/mail-logs/:/var/log/mail/ - ./docker-data/dms/config/:/tmp/docker-mailserver/ - ./config/dovecot/10-custom.conf:/etc/dovecot/conf.d/10-custom.conf - ./certs/:/certs - /etc/localtime:/etc/localtime:ro ```

Is it the same volume mount as you've got in your docker run snippet above?

Yes, I think. ```bash docker run --rm -it \ -v "${PWD}/docker-data/certbot/certs/:/etc/letsencrypt/" \ -v "${PWD}/docker-data/certbot/logs/:/var/log/letsencrypt/" \ -p 80:80 \ certbot/certbot certonly --standalone -d mymailhost.com ```

I am guessing you're following the Certbot LetsEncrypt advice in our docs?

The only problem I have is that the same server also runs Nextcloud. So, I manually update my ssl certs by shutting down the Nextcloud dockers, and then running the above docker run commands.

If it's using an old certificate, maybe look at what the container itself sees.

Can you kindly tell me how to do this? How do I find out what the container sees?

It's possible that it's not aware of the updated file contents internally. If the file has changed, then probably what needs to happen is Postfix/Dovecot is restarted, this should happen by default unless you're using LDAP.

No I am not using LDAP (I wanted to, but could not figure out how to. Am not very familiar with LDAP.)

If you are using LDAP you'll have to manually restart the DMS service (docker compose up --force-recreate) and it should work then. In future that may not be required, just requires some additional work to our change detector support.

I did `docker compose up --force-recreate` anyway but I get loads of errors like this: ``` mailserver | Jul 23 10:07:46 mymailhost postfix/smtps/smtpd[1530]: Anonymous TLS connection established from unknown[xx.xxx.xx.xxx]: TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits) mailserver | Jul 23 10:07:48 mymailhost postfix/smtps/smtpd[1512]: warning: unknown[xx.xxx.xx.94]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 mailserver | Jul 23 10:07:48 mymailhost postfix/smtps/smtpd[1507]: lost connection after AUTH from unknown[xx.xxx.xx.xxx] mailserver | Jul 23 10:07:48 mymailhost postfix/smtps/smtpd[1507]: disconnect from unknown[xx.xxx.xx.116] ehlo=1 auth=0/1 rset=1 commands=2/3 mailserver | Jul 23 10:07:49 mymailhost postfix/smtps/smtpd[1541]: lost connection after AUTH from unknown[xx.xxx.xx.147] mailserver | Jul 23 10:07:49 mymailhost postfix/smtps/smtpd[1541]: disconnect from unknown[xx.xxx.xx.147] ehlo=1 auth=0/1 rset=1 commands=2/3 mailserver | Jul 23 10:07:50 mymailhost postfix/smtps/smtpd[1512]: lost connection after AUTH from unknown[xx.xxx.xx.94] mailserver | Jul 23 10:07:50 mymailhost postfix/smtps/smtpd[1512]: disconnect from unknown[xx.xxx.xx.94] ehlo=1 auth=0/1 rset=1 commands=2/3 mailserver | Jul 23 10:07:57 mymailhost dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=xxx.xxx.xx.xx, lip=xxx.xx.x.x, TLS: read(size=719) failed: Connection reset by peer, session=<zF3eDyABYMl6sFhV> mailserver | Jul 23 10:07:58 mymailhost postfix/smtps/smtpd[1507]: connect from unknown[xxx.xx.xx.xxx] ``` Appreciate your help. Thanks, V.

1 reply

polarathene Jul 25, 2023
Maintainer

Can you kindly tell me how to do this? How do I find out what the container sees?

You can use docker exec -it container_name bash which should give you a shell into the container. From there you can run commands to inspect.

Postfix and Dovecot should be using internal copies of provided certs at this location:

docker-mailserver/target/scripts/helpers/ssl.sh

Line 28 in a0fde8b

local DMS_TLS_PATH='/etc/dms/tls'

But for LetsEncrypt / CertBot, these presently have no internal copy and live at the path shown here:

docker-mailserver/target/scripts/helpers/ssl.sh

Lines 191 to 196 in a0fde8b

    
           # LetsEncrypt `fullchain.pem` and `privkey.pem` contents are detailed here from CertBot: 
        
           # https://certbot.eff.org/docs/using.html#where-are-my-certificates 
        
           # `key.pem` was added for `simp_le` support (2016): https://github.com/docker-mailserver/docker-mailserver/pull/288 
        
           # `key.pem` is also a filename used by the `_extract_certs_from_acme` method (implemented for Traefik v2 only) 
        
           local PRIVATE_KEY="/etc/letsencrypt/live/${LETSENCRYPT_DOMAIN}/${LETSENCRYPT_KEY}.pem" 
        
           local CERT_CHAIN="/etc/letsencrypt/live/${LETSENCRYPT_DOMAIN}/fullchain.pem"

You can use ls -lah at the cert directory shown above inside the container. It should show you the date of the file, which may not be the renewed date if it still sees only the old cert.

Looking at our change detection code, we monitor custom cert ENV paths (trigger copy to internal location), and acme.json (Traefik update, trigger create new letsencrypt certs):

docker-mailserver/target/scripts/check-for-changes.sh

Lines 147 to 160 in a0fde8b

    
           if [[ ${SSL_TYPE} == 'manual' ]]; then 
        
             # only run the SSL setup again if certificates have really changed. 
        
             if [[ ${CHANGED} =~ ${SSL_CERT_PATH:-${REGEX_NEVER_MATCH}} ]]     \ 
        
             || [[ ${CHANGED} =~ ${SSL_KEY_PATH:-${REGEX_NEVER_MATCH}} ]]      \ 
        
             || [[ ${CHANGED} =~ ${SSL_ALT_CERT_PATH:-${REGEX_NEVER_MATCH}} ]] \ 
        
             || [[ ${CHANGED} =~ ${SSL_ALT_KEY_PATH:-${REGEX_NEVER_MATCH}} ]] 
        
             then 
        
               _log_with_date 'debug' 'Manual certificates have changed - extracting certificates' 
        
               _setup_ssl 
        
             fi 
        
           # `acme.json` is only relevant to Traefik, and is where it stores the certificates it manages. 
        
           # When a change is detected it's assumed to be a possible cert renewal that needs to be 
        
           # extracted for `docker-mailserver` services to adjust to. 
        
           elif [[ ${CHANGED} =~ /etc/letsencrypt/acme.json ]]; then

For LetsEncrypt since no extra processing is needed, we just watch these locations:

docker-mailserver/target/scripts/helpers/change-detection.sh

Lines 55 to 63 in a0fde8b

    
           elif [[ ${SSL_TYPE:-} == 'letsencrypt' ]]; then 
        
             # React to any cert changes within the following LetsEncrypt locations: 
        
             STAGING_FILES+=( 
        
               /etc/letsencrypt/acme.json 
        
               /etc/letsencrypt/live/"${SSL_DOMAIN}"/*.pem 
        
               /etc/letsencrypt/live/"${HOSTNAME}"/*.pem 
        
               /etc/letsencrypt/live/"${DOMAINNAME}"/*.pem 
        
             ) 
        
           fi

When any of those changes are detected, they will reload Postfix and Dovecot (slightly different than restart):

docker-mailserver/target/scripts/check-for-changes.sh

Lines 56 to 57 in a0fde8b

    
           _reload_postfix 
        
           [[ ${SMTP_ONLY} -ne 1 ]] && dovecot reload

So technically that should all be working correctly for you.

In the container shell, you could type supervisorctl restart postfix and supervisorctl restart dovecot, which should manually restart the services. Then provided the container does see the new certificate files, those commands should definitely have updated DMS to use them.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Docker Mailserver

letsencrypt certificate expired #3429

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Docker Mailserver

letsencrypt certificate expired #3429

Uh oh!

Uh oh!

vikasrawal Jul 16, 2023

Replies: 2 comments · 1 reply

Uh oh!

polarathene Jul 18, 2023 Maintainer

Uh oh!

Uh oh!

vikasrawal Jul 23, 2023 Author

Uh oh!

polarathene Jul 25, 2023 Maintainer

vikasrawal
Jul 16, 2023

Replies: 2 comments 1 reply

polarathene
Jul 18, 2023
Maintainer

vikasrawal
Jul 23, 2023
Author

polarathene Jul 25, 2023
Maintainer