Hi together,
while working on s/qmail 4.1 (which is running an incomplete beta on my root server), I made same observations in conjunction with Apple Mail (MacOS and iOS) together with Let's Encrypt certificates, which I would like to share:
1. On my domain 'fehcom.de' I have a Lets's encrypt X.509 cert installed (for HTTPS some mail applications) which is frequently checked and updated (by ACME).
2. On my domain 'fehcom.net' a (mostly static) self-signed is in place.
* Requirement for changing X.509 certs:
For Apache2 (my web server) and my s/qmail services (SMTP, STMPS, Submission, QMTPS, POP3, POP3S together with BincIMAPS) a certificate change REQUIRES to re-start the applications (in my case apache2 and qmail-pop3s; the other services use the self-signed certs in order not to depend on a third party).
* Observation 1:
If you don't do that, X.509 verification will fail (curl, wget ....) or at least comply.
* The Appe case (MacOS and iOS):
Apple has build in some automatics for certificate verification for their Mail App which are outside the user's control and not always work as supposed:
a) iOS MailApp may take minutes to accept the TLS handshake:
2020-12-06 20:36:04.751171500 sslserver: ok 29194 mail.fehcom.net:85.25.149.179:110 dslc-082-083-091-021.pools.arcor-ip.net:82.83.91.21::61845
2020-12-06 20:36:04.952579500 sslserver: tls 29194 accept TLSv1.3:TLS_AES_128_GCM_SHA256
2020-12-06 20:39:55.978858500 qmail-popup: pid 29194 Accept::AUTH::User P:POP3S S:82.83.91.21:dslc-082-083-091-021.pools.arcor-ip.net ?~ 'x@y'
2020-12-06 20:39:56.025918500 sslserver: ended by 29189 status 256
However, the variation on these times is significant (few secs to 10 mins).
b) iOS as well as MacOS Mail App have an automatism to cope with X.509 cert changes and which may lead to the following situation for sslserver (after a cert refreshment; this was the trigger of the current post). This here is for MacOS Mail App using POP services:
2021-01-10 09:54:34.094642500 sslserver: ok 10605 mail.fehcom.net:85.25.149.179:995 p5dc8f774.dip0.t-ipconnect.de:93.200.247.116::49570
2021-01-10 09:55:00.139025500 sslserver: error: (111) unable to accept TLS for pid: 10605 system lib
However, after some connection trials the new cert was accepted.
* Observation 2:
Apple has some 'strange' ways of accepting X.509 certificates with own rules. Apart from the validity of the X.509 cert (e.g. expiring date), within Applies logic it seems to be most important to put the cert in the OS Trust Store. For the user - given this operation requires confirmation - there is no hook to get knowledge about WHAT was accepted. In previous versions of iOS there was at leat a button, asking for cert confirmation; but this is gone in the current iOS.
This blind believe in X.509 certs and the automatisms in place is in-acceptable. This not only takes place for mail (where certs are just used to prevent a man-in-the-middle) but also for Web browsers. In particular, in Safari all information about the X.509 cert in invisible, where for example Opera lets you digest the cert.
Is one SolarWind event not enough?
Regards.
--eh.
PS: I would like to share experiences with you and asking for comments.
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
while working on s/qmail 4.1 (which is running an incomplete beta on my root server), I made same observations in conjunction with Apple Mail (MacOS and iOS) together with Let's Encrypt certificates, which I would like to share:
1. On my domain 'fehcom.de' I have a Lets's encrypt X.509 cert installed (for HTTPS some mail applications) which is frequently checked and updated (by ACME).
2. On my domain 'fehcom.net' a (mostly static) self-signed is in place.
* Requirement for changing X.509 certs:
For Apache2 (my web server) and my s/qmail services (SMTP, STMPS, Submission, QMTPS, POP3, POP3S together with BincIMAPS) a certificate change REQUIRES to re-start the applications (in my case apache2 and qmail-pop3s; the other services use the self-signed certs in order not to depend on a third party).
* Observation 1:
If you don't do that, X.509 verification will fail (curl, wget ....) or at least comply.
* The Appe case (MacOS and iOS):
Apple has build in some automatics for certificate verification for their Mail App which are outside the user's control and not always work as supposed:
a) iOS MailApp may take minutes to accept the TLS handshake:
2020-12-06 20:36:04.751171500 sslserver: ok 29194 mail.fehcom.net:85.25.149.179:110 dslc-082-083-091-021.pools.arcor-ip.net:82.83.91.21::61845
2020-12-06 20:36:04.952579500 sslserver: tls 29194 accept TLSv1.3:TLS_AES_128_GCM_SHA256
2020-12-06 20:39:55.978858500 qmail-popup: pid 29194 Accept::AUTH::User P:POP3S S:82.83.91.21:dslc-082-083-091-021.pools.arcor-ip.net ?~ 'x@y'
2020-12-06 20:39:56.025918500 sslserver: ended by 29189 status 256
However, the variation on these times is significant (few secs to 10 mins).
b) iOS as well as MacOS Mail App have an automatism to cope with X.509 cert changes and which may lead to the following situation for sslserver (after a cert refreshment; this was the trigger of the current post). This here is for MacOS Mail App using POP services:
2021-01-10 09:54:34.094642500 sslserver: ok 10605 mail.fehcom.net:85.25.149.179:995 p5dc8f774.dip0.t-ipconnect.de:93.200.247.116::49570
2021-01-10 09:55:00.139025500 sslserver: error: (111) unable to accept TLS for pid: 10605 system lib
However, after some connection trials the new cert was accepted.
* Observation 2:
Apple has some 'strange' ways of accepting X.509 certificates with own rules. Apart from the validity of the X.509 cert (e.g. expiring date), within Applies logic it seems to be most important to put the cert in the OS Trust Store. For the user - given this operation requires confirmation - there is no hook to get knowledge about WHAT was accepted. In previous versions of iOS there was at leat a button, asking for cert confirmation; but this is gone in the current iOS.
This blind believe in X.509 certs and the automatisms in place is in-acceptable. This not only takes place for mail (where certs are just used to prevent a man-in-the-middle) but also for Web browsers. In particular, in Safari all information about the X.509 cert in invisible, where for example Opera lets you digest the cert.
Is one SolarWind event not enough?
Regards.
--eh.
PS: I would like to share experiences with you and asking for comments.
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE