Did the original patch take the wrong approach? It seemed to let you specify a regex to match the CERTIFICATE (CN) against. But all of the examples given so far already KNOW what the CN on the certificate is going to be...

For those examples, it seems we need to specify a particular CN (which *could* be "*.company.com", where the * is NOT a wildcard, but a literal character) that we expect to receive for a given request, even though it may not match the hostname in use.

Or, if you want to be fancy, you could setup some kind of regex or wildcard match against the HOSTNAME (which would be useful, if for example www.mycompany.com redirected you to www2.mycompany.com, but both used the same cert).

So, for example:

  --expect-CN www.mycompany.com --url https://www2.mycompany.com

or, if supporting -L is needed:

  --host-to-CN-mapping "*.mycompany.com"=www.mycompany.com

- Kevin

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
Received on 2003-06-04