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/CN=DanielRuggeri.bitnebula.com
</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)
SSLPROXY_CERT_CB_LOG_FMT
"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.
--
Daniel Ruggeri
