-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel,
On 8/31/20 11:36, Daniel Savard wrote: > Le lun. 31 août 2020 à 11:13, Christopher Schultz < > ch...@christopherschultz.net> a écrit : > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> >> Daniel, >> >> On 8/28/20 20:46, Daniel Savard wrote: >>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker < >>> darryl.ba...@northwestern.edu> a écrit : >>> >>>> I am having an issue that I don’t understand. On >>>> RHEL6/CentOS and earlier my predecessors would put >>>> self-signed certificates they wanted to trust in >>>> /etc/pki/ca-trust/extracted/java/cacerts and it was good for >>>> the life of the machine. On RHEL7 and I assume CentOS7 that >>>> file is part of a package that is getting updated as part of >>>> the regular patches. That wipes out our self-signed >>>> certificates. The way I understand the directions from Red >>>> Hat we should put the certificate in pem format in the >>>> directory /etc/pki/ca-trust/source/anchors and run >>>> update-ca-trust extract and that will update the all the >>>> appropriate files. Including the cacerts file. That does not >>>> seem to happen. What is the proper way of handling >>>> self-signed certificates you want tomcat to trust? >>>> >>>> Off topic but you are folks who might know: On a related note >>>> I have the same issue with Java applications not running in >>>> Tomcat that use the same file /etc/pki….java/cacerts. Am I >>>> understanding the PKI update process correctly? Am I putting >>>> the self-signed certificate pem format file in the correct >>>> place? >>>> >>>> Darryl Baker, GSEC (he/him/his) Sr. System Administrator >>>> (...) >>>> >>>> >>> You can put your certificates and truststore wherever you want >>> as long as you tell Tomcat where they are in the >>> conf/server.xml configuration file when you configure the >>> connector using them. >>> >>> Self-signed certificates should never be used on a production >>> server, they are not secure. >> What makes you say that? >> >> - -chris (...) > > > > https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-a re-turning-strength-into-a-vulnerability This > article is talking about securing miscreants' communications. It really has nothing to do with self-signed certificates. It has to do with users blindly "trusting" anything which claims to be trustworthy just because it's encrypted. Self-signed certificates by definition are not signed by a CA, so they are not globally-trusted (or even semi-globally-trusted). "Trusting All" certificates is a terrible mistake and the only way that self-signed certificates can be a problem, whether used on an "internal" network or exposed to the outside network. > Never may be exaggerated in my post. But in general, you should > avoid them. Meh. > But it all depends on your organization as well, mine is signing > internal certificates and managing to include itself in the > browsers of all the thousands employees. This is a good technique IMO. > In a small business, it may not be possible and the number of > self-signed certificates may be low. In our organization, in the > past we have seen people setting up their own self-signed > certificates with too short keys to be secured by today's > standards. Well, that's obviously a mistake. Especially if you aren't talking about browser-trust, I think self-signed (or local-CA-signed) certificates are a good thing. Services ought to be individually-trusting service certificates and not even accepting all globally-recognized CAs because a compromised CA or middle-box can intercept communications without a problem. Self-signed certificates offer isolation from CAs and can therefore be *more* secure for service-level certificates precisely because they require special deployment. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXWQACgkQHPApP6U8 pFicIxAAj04SbtcGa7UuCb65EvME1XAqRRwmsHVBGhLxBK/Nr3g+hDZ9xFd9Yo4i 5iuQ0yat4lD2y8BH1YF+EHrygfIp86EoDUKKukjuoAVQ4cgHFM6T2aoM8sWJR1CJ xoxbA+dWnYL12BZR6jRj2k5vcOvs/UYkz4A6dp9X2N1LaQHMw5/orrqLPwN/BxiZ qTzeEKqMAhLsfGVZVs9VGZPMLZYL6TvMkca22IltK1Z3dDkalijwyL83Q7vVGEvm 38qamO3FkgnfjZPgufkVoxfEKkG3lmMY7kpzxvGeoaPaH3he3tljXXVGbKxfSAuX NFYj1CciL2fJCGm0roIB/9kPvG3Eoiq96ubUwbpl2fIciMA+XFJ6nUDj0ogdHzl1 yYbAowAXN4YR7azmmhwSUzgUsaw5itAQxiQpb0A7G3yxmTt52xv62aV5PhDw0lsN HULi7GFm6JoeuzaGW6KBcOfBu+hZpek1Jqujn/Y435jIU5otE9R+yYDtdonLD0W3 ssWGdZRP6/Rgu41BEMPpdCgb+lDWBH/EkuTFHDerX2u9kpjALuJTTPRyt2REpOqY Oflifwm2f9R77J3LNK8CNqC9d1BtUJqwSJ5/u+dRpkExYzTf37mHkt2kmdDlZJYi mpjJUuoyEZnxhltyrp8Wn5bWNnA6P4kzVcPGqbG3MM/1KIHs++k= =kmkH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
