httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Thu, 14 Apr 2016 08:08:54 GMT
Am 14.04.2016 um 02:57 schrieb Daniel Ruggeri:
> On 4/13/2016 2:22 PM, Rainer Jung wrote:
>> We could pass the worker name from mod_proxy to mod_ssl via a
>> connection note, similar to currently already passing the SNI name via
>> the connection note proxy-request-hostname.
> +1 on the connection note idea, but see below about having to inform the
> callback function about too much information
> On 4/13/2016 10:04 AM, Graham Leggett wrote:
>> What I had in mind was a syntax where the certs were named, for example:
>> SSLProxyCertificate foo /path/to/foo.cert
>> Followed somewhere else by:
>> <Proxy …>
>>    SSLProxyEnable foo
>> </Proxy>
> On one hand, this is an attractive idea because we have already
> conditioned users/administrators to think about naming things via config
> as you can do with authn providers and aliases.
> On another hand, there are two gotchas I see. Giving something a name in
> the configuration does not necessarily mean anything to the file or
> certificate store because they aren't married in the same way that authn
> providers and their aliases are. That is, if a different team/individual
> manages the certificate store than the server configuration, the two
> would have to keep in sync with additions or removals. This can be a
> PITA if you have a short certificate lifecycle and have to renew often.
> PLUS, there are cases where there may be many certificates in the file.
> Combine that with the previous point and you could have a nightmare.
> Perhaps in addition to or instead of aliases via config, something more
> "dynamic" could be used where a DN, CN or some other attribute about the
> cert that was parsed during startup becomes the representation?
> <vhost...>
>     ...
>    #As today
>     SSLProxyMachineCertificateFile /path/to/file
>     <Proxy ...>
>        #Plus new stuff
>        SSLProxyMachineCertificateCN myIdentity
>        #or
>        SSLProxyMachineCertificateDN /C=US/ST=Missouri/L=St.
> Louis/O=BitNebula/
>     </Proxy>
> </vhost>
> This could be a really clean solution because the proxy can just pass
> this name or DN to the ssl module in a note and the ssl module could
> make the selection of certs from that data.
> Stashing this (completely untested and thrown together) code around line
> 1778 in modules/ssl/ssl_engine_kernel.c could be all that's needed in
> mod_ssl....
>      char *preferred_name;
> ......
>      if (preferred_name) {
>          for (i = 0; i < sk_X509_INFO_num(certs); i++) {
>              X509_NAME *name;
>              info = sk_X509_INFO_value(certs, i);
>              name = X509_get_subject_name(inf->x509);
>              for(j = 0; j < X509_NAME_entry_count(name); j++) {
>                  const char *this_name = //something
>                  if (strcmp(preferred_name, this_name) == 0) {
>                      modssl_proxy_info_log(c, info, APLOGNO(02279)
>                                            "found acceptable cert");
>                      modssl_set_cert_info(info, x509, pkey);
>                      return TRUE;
>                  }
>              }
>          }
>          ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(000000)
>              "server configuration requested certificate name %s"
>              "but it was not found in the certificate store",
> preferred_name);
>      }
> I haven't cracked open the proxy code to see what it would take to
> collapse this down to a per proxy/worker/etc, but it doesn't seem like
> terrible endeavor.

Yeah that's looks very feasible and would allow the actual use case. I 
was wondering whether more SSLProxy* directives would benefit from a per 
backend config possibility. And as a variation of Graham's suggestion, I 
was thinking about (example)

<Proxy http://mycluster>
     SSLProxyMachineCertificateFile /path/to/file
     ... proxy settings ...

In the vhost config we would not then have an array or hash of ssl proxy 
ocnfig setting. The key to the hash would be "http://mycluster" in the 
example above. And mod_proxy would forward "http://mycluster" to mod_ssl 
via connection notes to allow mod_ssl to select the right proxy ssl config.

So there would be no additional name "foo", instead we would reuse the 
name of the worker from the surrounding proxy block. The selection of 
the certificate would still happen based on the CA, but it would be 
selected from the right store (the one associated with "http://mycluster").

I see your point about having to administer more ssl files outside of 
the config, ie. client cert files or directories per backend. I would 
hope that those would be manageable by choosing some naming convention 
for the file names.

Your idea to allow selecting a client cert based on CN or DN sounds 
attractive to me as well. But since it wouldn't help with other per 
backend settings (like different Verify settings) we might even think 
about combining both. As long as your only problem would be client 
certs, you can select via CN or DN and keep the config vhost global, but 
once you need more adjustments per backend, you would start to configure 
SSLProxy* inside <Proxy ...>.




View raw message