Open thelounge-zz opened 1 year ago
patch attached trafficserver-9.2-issue-10040.patch.txt
FWIW, we follow the same conventions (dual algorithms, single file for private key/certs etc), but don't get such logs. I wonder if you actually do have a real issue, and the dual algorithms are smoothing it over -- like your ECDSA key for example.com is missing the key, but the RSA one isn't, and thus clients can still connect. Patch wise, I don't think it makes sense to not complain about this case -- fixing a bug in secret_key_data.empty() would make much more sense.
listen: if there would be keys missing https://www.ssllabs.com/ssltest/ won't be green for both ECDSA and RSA over years and hundrets of certs, the certs are all generated by a script used at two independent comanies with hundrets of hosts and certificates
you can see the strcuture of both certificate types above both END-BEGIN are a real copy&paste from a certificate only the base64-part stripped
and to be honest: dumping the whole certificate into "diags.log" but NOT mention the certificate file is a poor action to begin with - even if the warning would be true (which isn't for 100% sure) you can only guess - at least i don't know the base64 contents of my certificate files renewed avery few month from my mind :-) and spit private keys into logfiles is a nogo
since it's a testserver and the certificates are expiring regulary i could eben provide /etc/trafficserver/ssl_multicert.config and the whole /var/lib/letsencrypt/certs/ folder with the 14 certificate files
FWIW: i just upgraded from 8.1.7 to 9.2.1 with my patch applied on production and ssllabs.com confirms everything is fine for dual-stack letsencrypt hosts as well as for RSA-only "manually generated and supplied" certificates for exceptional customers - so that logging is simply nonsense no matter where it is triggered
I think it's a legitimate concern to not have the contents of the file printed to the console here (it would probably be better to print the name of the file).
"Demote SSL log line to debug and remove key printing" with 9.2.2 makes my patch obsolete and works as expected with the same certificates for years - frankly how many years do i need to wait before apply version cheanges? MariaDB 10.4 breaks tests for 3 years because of a no longer existing config-option, ATS after years spits nonsense until i upgrade - i get sick and tired of the whole IT business
This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.
i don't know what this warning means at all - eveyrthing seems to work fine - i guess it's about no password for certs which don't make sense for letsecrypt
bad enough that you flood "diags.log" with hundrets of warnings you are also dumping the whole certificates and kyes into the logfile
https://github.com/apache/trafficserver/blob/master/iocore/net/SSLUtils.cc
our (dual-stack) certificates are structured like this for many years, are working fine for httpd, trafficserver, dovecot, postfix
RSA: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----
ECDSA: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- -----END EC PRIVATE KEY----- -----BEGIN EC PARAMETERS----- -----END EC PARAMETERS-----
[root@testserver:/var/log/trafficserver]$ cat /etc/trafficserver/ssl_multicert.config ssl_cert_name=/var/lib/letsencrypt/certs/test.conf_rsa.pem,/var/lib/letsencrypt/certs/test.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/mailadmin.conf_rsa.pem,/var/lib/letsencrypt/certs/mailadmin.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/uploadprogress.conf_rsa.pem,/var/lib/letsencrypt/certs/uploadprogress.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/contentlounge.conf_rsa.pem,/var/lib/letsencrypt/certs/contentlounge.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/0000-default.conf_rsa.pem,/var/lib/letsencrypt/certs/0000-default.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/corecms.conf_rsa.pem,/var/lib/letsencrypt/certs/corecms.conf_ecdsa.pem ssl_cert_name=/var/lib/letsencrypt/certs/webmail.conf_rsa.pem,/var/lib/letsencrypt/certs/webmail.conf_ecdsa.pem