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/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.
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 ...
</Proxy>
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 ...>.
WDYT?
Regards,
Rainer
