On 07/19/2017 07:27 PM, Amos Jeffries wrote: > 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.
I doubt I can grasp all the side effects, but what you are proposing sounds very good to me in principle. If your arguments are valid, then I would go further, for exactly the same reasons you are giving above: I suggest deprecating abused cert/key pair and having a new option for the regular _port certificate/key. For example: https_port port-certificate=... generate-host-certificates=... and then I would also deprecate generate-host-certificates instead of abusing a boolean option to specify an essentially required argument, arriving at something like this: https_port port-certificate=... ssl-bump-ca-certificate=... and refuse to accept non-CA certificates in ssl-bump-ca-certificate. The "port-" prefix can be dropped but I think having two different prefixes for two certificates is better. HTH, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
