I have not used v4 yet but the arguments stand for themselves. +1 Eliezer
---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: elie...@ngtech.co.il -----Original Message----- From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Thursday, July 20, 2017 04:27 To: Squid Developers <squid-dev@lists.squid-cache.org> Subject: [squid-dev] [RFC] http(s)_port TLS/SSL config redesign Hi all, Christos and Alex particularly, I have been mulling over several ideas for how to improve the config parameters on the http(s)_port to make them a bit easier for newbies to get right, and pros to do powerfully cool stuff. So, the most major change I would like to propose is to move the proxies CA for cert generation from cert= parameter to generate-host-certificates= parameter. Having it configured with a file being the same as generate =on and not configuring it default to =off. The matching key= and any CA chain would need to be all bundled in the same PEM file. That should be fine since the clients get a separate DER file installed, not sharing the PEM file loaded into Squid. That will stop confusing newbies have over what should go in cert= for what Squid use-case. And will allow pros to configure exactly which static cert Squid uses as a fallback when auto-generating others - simply by using cert= in the normal non-bumping way. Also, we can then easily use the two sets of parameters in identical fashion for non-SSL-Bump proxies to auto-generate reverse-proxy certs based on SNI, or use a fallback static cert of admins choice. Bringing these two different use-cases config into line should vastly simplify the complexity of working with Squid TLS certs for everybody, including us in the code as we no longer have multiple (8! at least) code paths for different cert= possibilities and config error handling permutations. For backward compatibility concerns with existing SSL-Bump configs I think we can use the certificate CA vs non-CA property to auto-detect old SSL-Bump configs being loaded and handle the compatibility auto-upgrade and warnings. The warning will be useful long-term and not just for the transitional period. Now would also be a marginally better than usual time to make the change since the parameters are migrating to tls-* prefix in v4 and have extra admin attention already. Amos _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev