Menu

#13 add option CertificateFileStrict to reject invalid certs from CertificateFile

unknown
open
nobody
None
unknown
5
2020-08-03
2017-03-30
Edd Barrett
No

I have a setup using a CertificateFile directive a bit like this:

IMAPAccount XXX
Host XXX
...
SSLType IMAPS
CertificateFile /path/to/dovecot.pem

The certificate has expired:

$ openssl x509 -text -in dovecot.pem -noout
Certificate:
...
        Validity
            Not Before: Dec 27 00:42:30 2014 GMT
            Not After : Dec 26 00:42:30 2016 GMT

Yet I've never seen mbsync warn me about this. Shouldn't it refuse to work, or at the very least emit a warning?

Thanks

Discussion

  • Edd Barrett

    Edd Barrett - 2017-03-30

    I've just found this in the docs:

           CertificateFile path
                  File containing additional X.509 certificates used to verify
                  server identities. Directly matched peer certificates are always
                  trusted, regardless of validity.
    

    I'd argue that probably isn't a great idea.

     
  • Oswald Buddenhagen

    given that the primary purpose of this option is forcibly accepting certs which are somehow invalid - specifically expired - refusing to work just isn't an option in the general case. however, there have been requests for more paranoid cert handling before, and in particular in conjunction with 'SystemCertificates no' it makes some sense. i suppose i could add an option CertificateFileStrict or some such.

     
  • Oswald Buddenhagen

    Ticket moved from /p/isync/bugs/29/

    Can't be converted:

    • _milestone: 1.2.1
    • _fixed_in: unknown
     
  • Oswald Buddenhagen

    • summary: isync's CertificateFile doesn't reject expired SSL certs --> add option CertificateFileStrict to reject invalid certs from CertificateFile
    • status: reported --> open
    • Missing In: 1.2.1 --> unknown
    • Implemented In: --> unknown
     
  • Oswald Buddenhagen

    i've had another look at this and my tentative conclusion is again that this makes little sense:
    if you specify a host cert, you do that to bypass the regular CA chain.
    if you specify a CA root (or just rely on the system's trust store), then the cert chain will be fully validated. in that case you aren't supposed to specify the host cert as well.
    the only use case where it would matter is if you specify a host cert that is self-signed (so the CA-based path is not taken). given that this is a rare case where you'd likely have full control over the cert, would you really expect mbsync to do the complaining about expiration?

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.