Letsencrypt tip

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How to check for upcoming certificate expiration...

Viktor Dukhovni
On Wed, Sep 13, 2017 at 09:09:36AM +0300, Dominic Raferd wrote:

> On 11 September 2017 at 19:25, Viktor Dukhovni <[hidden email]>
> wrote:
>
> - what do I specify for the CAfile?

That depends on where the operating system distribution squirrels
away the usual root CA certificates.  You can typically find out
where OpenSSL looks by default, e.g.

        $ openssl version -d
        OPENSSLDIR: "/etc/ssl"

which means that the CAfile defaults to "/etc/ssl/cert.pem" and
CApath to "/etc/ssl/certs".  You might find the requisite root
CA certificates "there" (wherever "openssl version -d" reports).

A more precise choice would be a file with the specific root CA
certificate that you expect to issue the certificate of the servers
you want to test (presumably your own, so you'd know which CAs to
expect).

> - does this check against the certificates being offered both by Postfix
> and Dovecot (which I use for SASL) or just one of them and if so which one?​

The bash code in question connects to SMTP servers (-starttls smtp).
The s_client(1) CLI also supports "-starttls imap" (STARTTLS over
IMAP on port 143) and of course can do an immediate TLS handshake
(for IMAP over TLS on port 993) so you could choose a suitable port
and just modify or delete the "-starttls smtp" option.

For OpenSSL 1.1.0 the bash script could also be enhanced to verify
DANE TLSA records (obtained via dig or similar).

The bash gymnastics serve two purposes:

    1.  Avoid temporary files that might need fragile cleanup code.
    2.  Capture stderr and only output such diagnostics on error.

The script would have been a lot simpler if I were willing have it
be noisy even on success and leak temp files.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Letsencrypt tip

Dominic Raferd
In reply to this post by Dominic Raferd


On 11 September 2017 at 17:22, Dominic Raferd <[hidden email]> wrote:
On 11/09/2017 12:33, Christian Kivalo wrote:
On 2017-09-11 11:21, Dominic Raferd wrote:
​Does anyone know a way to detect if the certificate currently being
used by Postfix and/or Dovecot is nearing expiry (esp. in case they
haven't picked up the updated letsencrypt certificate)?
​...​


This example gives exit code 1 if the certificate has less than 3 days (259200 seconds) to expiry:

​​
echo|sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp -servername my.domain.tld 2>/dev/null|openssl x509 -noout -checkend 259200

​As postfix SMTP server does not support SNI I think there is no point using -servername option above, so the above can be shortened to:

echo | sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp 2>/dev/null | openssl x509 -noout -checkend 259200​

If checking a remote server, substitute 127.0.0.1 with the remote address.

I'm still unclear whether the test is against the certificate data that is held within postfix or that is held within the SASL application (dovecot or cyrus).
Reply | Threaded
Open this post in threaded view
|

Re: Letsencrypt tip

Viktor Dukhovni

> On Sep 13, 2017, at 4:10 AM, Dominic Raferd <[hidden email]> wrote:
>
> As Postfix SMTP server does not support SNI I think there is no point using
> -servername option above, so the above can be shortened to:
>
> ​echo |
> sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp 2>/dev/null |
> openssl x509 -noout -checkend 259200​

There definitely good reason to avoid "sudo", which is unnecessary here.
As for SNI, indeed not needed if the server being tested is known to be
Postfix.

> I'm still unclear whether the test is against the certificate data that
> is held within postfix or that is held within the SASL application
> (dovecot or cyrus).

Now you betray some confusion, SASL is NOT TLS and does not exchange
certificates with the SASL client.  The application protocol that
supports SASL may run over TLS, in which case the server and sometimes
also the client might present X.509 certificates, but SASL could not
possibly do that absent a "TLS" mechanism for SASL that would use
client certificates for authentication and then TLS as the SASL
"security layer".  AFAIK no such mechanism exists, and Postfix has no
support for SASL "security layers" in any case.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: How to check for upcoming certificate expiration...

Łukasz Wąsikowski
In reply to this post by Viktor Dukhovni
W dniu 2017-09-11 o 18:25, Viktor Dukhovni pisze:

>
>> On Sep 11, 2017, at 5:21 AM, Dominic Raferd <[hidden email]> wrote:
>>
>> Does anyone know a way to detect if the certificate currently being used by Postfix and/or Dovecot is nearing expiry (esp. in case they haven't picked up the updated letsencrypt certificate)?
>
> See below for OpenSSL 1.0.2 or later.  Earlier versions don't
> have the "-verify_hostname" option, you can delete it if you
> like, and omit that part of the certificate check, in which
> case the code will also work for OpenSSL 1.0.1 and earlier
> (which are EOL).

https://github.com/matteocorti/check_ssl_cert works great. I'm using it
to check my local / remote HTTP/SMTP/IMAP certificate expiry dates.

--
best regards,
Lukasz Wasikowski
Reply | Threaded
Open this post in threaded view
|

Re: How to check for upcoming certificate expiration...

Viktor Dukhovni

> On Sep 13, 2017, at 3:43 PM, Łukasz Wąsikowski <[hidden email]> wrote:
>
>> See below for OpenSSL 1.0.2 or later.  Earlier versions don't
>> have the "-verify_hostname" option, you can delete it if you
>> like, and omit that part of the certificate check, in which
>> case the code will also work for OpenSSL 1.0.1 and earlier
>> (which are EOL).
>
> https://github.com/matteocorti/check_ssl_cert works great. I'm using it
> to check my local / remote HTTP/SMTP/IMAP certificate expiry dates.

That's certainly a lot more features.  I can't easily verify that
all the checks are correct in a script of that size, so caveat
emptor.

Its expiration time verification is based in parsing certificate
dates rather than asking "openssl verify" to do a future verification.
This is less robust, because it can miss expiration of intermediate
certificates, when they happen to expire before the leaf certificate
(perhaps a failure to install the most recent intermediate issuer).

My short script certainly won't come close to matching that Swiss-
army-knife on features, but it may do the one thing that it does
more correctly.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Letsencrypt tip

Dominic Raferd
In reply to this post by Viktor Dukhovni


On 13 September 2017 at 19:54, Viktor Dukhovni <[hidden email]> wrote:

> On Sep 13, 2017, at 4:10 AM, Dominic Raferd <[hidden email]> wrote:
>
> As Postfix SMTP server does not support SNI I think there is no point using
> -servername option above, so the above can be shortened to:
>
> ​echo |
> sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp 2>/dev/null |
> openssl x509 -noout -checkend 259200​

There definitely good reason to avoid "sudo", which is unnecessary here.
As for SNI, indeed not needed if the server being tested is known to be
Postfix.

​Thanks for the correction and confirmation

> I'm still unclear whether the test is against the certificate data that
> is held within postfix or that is held within the SASL application
> (dovecot or cyrus).

Now you betray some confusion, SASL is NOT TLS and does not exchange
certificates with the SASL client.  The application protocol that
supports SASL may run over TLS, in which case the server and sometimes
also the client might present X.509 certificates, but SASL could not
possibly do that absent a "TLS" mechanism for SASL that would use
client certificates for authentication and then TLS as the SASL
"security layer".  AFAIK no such mechanism exists, and Postfix has no
support for SASL "security layers" in any case.

​Indeed I was confused! So I now understand that the certificate references in my ​/etc/dovecot/conf.d/10-ssl.conf:

ssl_cert = </etc/letsencrypt/live/mydomain.tld/fullchain.pem
ssl_key = </etc/letsencrypt/live/mydomain.tld/privkey.pem

are irrelevant for SMTP/SASL through Postfix, and are only relevant if the server is being accessed for POP3 or IMAP. From what I read at https://wiki.dovecot.org/SSL/DovecotConfiguration it seems that for Dovecot (unlike Postfix) a manual reload is needed to get it to re-read these certificates when they have changed. (All off-topic for Postfix, of course, sorry...) 
Reply | Threaded
Open this post in threaded view
|

Re: How to check for upcoming certificate expiration...

Łukasz Wąsikowski
In reply to this post by Viktor Dukhovni
W dniu 2017-09-13 o 22:11, Viktor Dukhovni pisze:

>> On Sep 13, 2017, at 3:43 PM, Łukasz Wąsikowski <[hidden email]> wrote:
>>
>>> See below for OpenSSL 1.0.2 or later.  Earlier versions don't
>>> have the "-verify_hostname" option, you can delete it if you
>>> like, and omit that part of the certificate check, in which
>>> case the code will also work for OpenSSL 1.0.1 and earlier
>>> (which are EOL).
>>
>> https://github.com/matteocorti/check_ssl_cert works great. I'm using it
>> to check my local / remote HTTP/SMTP/IMAP certificate expiry dates.
>
> That's certainly a lot more features.  I can't easily verify that
> all the checks are correct in a script of that size, so caveat
> emptor.
>
> Its expiration time verification is based in parsing certificate
> dates rather than asking "openssl verify" to do a future verification.
> This is less robust, because it can miss expiration of intermediate
> certificates, when they happen to expire before the leaf certificate
> (perhaps a failure to install the most recent intermediate issuer).
>
> My short script certainly won't come close to matching that Swiss-
> army-knife on features, but it may do the one thing that it does
> more correctly.

I've sent link to this thread to check_ssl_cert author, I hope your
advice will find a way to check_ssl_cert.

--
best regards,
Lukasz Wasikowski
12