What about these two small fixes for mod_ssl (which I already tried to
push for 2.3.11)?
- don't do OCSP checks for valid self-issued certs
- address PR 48215 ("Renegotiation with SSLVerifyDepth 0 requires
multiple client authentication")
The complete message is attached again, but the gist for the first patch is:
> I don't mind adding support for trusted responders, but until that
> happens, I consider hard-coding mod_ssl to skip OCSP checks for valid
> self-signed certs a sensible choice.
Assuming that trusted responder support won't be added anytime
soon, it would make sense to get this in before 2.4 GA, IMO.
Kaspar
--- Begin Message ---
On 10.02.2011 15:27, Jim Jagielski wrote:
> Let's commit to pushing for a 2.3.11-BETA...
I would certainly welcome that - what about the two (small) patches I
proposed about three weeks ago? Original message attached, for easier
reference.
Kaspar
--- Begin Message ---
On 17.01.2011 15:27, Dr Stephen Henson wrote:
> On 17/01/2011 13:39, Joe Orton wrote:
>> w.r.t. the change to skip OCSP validation for valid self-signed certs, I
>> brought this up a while back:
>>
>> http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
>>
>> and Stephen said it probably be configurable. Has common practice
>> evolved here such that hard-coding the less strict behaviour is
>> reasonable?
The only case where checking self-signed, self-issued certs really makes
sense is the one mentioned by Steve - when an OCSP responder with an
explicitly trusted public key is used (case #3 in Steve's mail, in RFC
2560 section 2.2 it's called "Trusted Responder"). Certainly not a
common configuration for "In_ter_net" deployments, but maybe of use for
corporate/In_tra_net environments.
> I still believe it should be configurable.
>
> A root CA can be revoked for a number of reasons although key compromise has
> security issues if the responder certificate is part of the chain (i.e. cases
> #1
> and #2 in that message).
Remember such a root cert (trust anchor) will previously have been
configured through SSLCACertificateFile/SSLCACertificatePath anyway, so
the only "advantage" of OCSP checks for these would actually be that it
amounts to some kind of "alerting" feature for the admin - making him
aware of invalid root certs in his trust store. Once realized, he would
then certainly be better off with completely removing these roots from
the httpd config.
> Apache OCSP AFAIK currently doesn't handle case #3 at all (trusting responders
> with keys trusted by some out of band means).
>
> There is a fix/enhancement for this (which also addresses the issue Steve
> Marquess brought up) in PR46037.
I don't mind adding support for trusted responders, but until that
happens, I consider hard-coding mod_ssl to skip OCSP checks for valid
self-signed certs a sensible choice. Even when support for trusted
responder is added, I don't think it needs to be configurable - it can
be enabled/disabled based on the existence of trusted responders in the
config (relying on the absence/presence of the OCSP_TRUSTOTHER verify
flag, effectively).
For convenience, I'm attaching the snippet which hasn't been committed yet.
Another small patch to mod_ssl, which I consider low-hanging fruit, is
attached to PR 48215
(https://issues.apache.org/bugzilla/attachment.cgi?id=24583).
Kaspar
Index: modules/ssl/ssl_engine_ocsp.c
===================================================================
--- modules/ssl/ssl_engine_ocsp.c (revision 1060819)
+++ modules/ssl/ssl_engine_ocsp.c (working copy)
@@ -252,6 +252,12 @@
apr_pool_t *vpool;
int rv;
+ /* don't do OCSP checking for valid self-issued certs */
+ if (cert->valid && X509_check_issued(cert,cert) == X509_V_OK) {
+ X509_STORE_CTX_set_error(ctx, X509_V_OK);
+ return 1;
+ }
+
/* Create a temporary pool to constrain memory use (the passed-in
* pool may be e.g. a connection pool). */
apr_pool_create(&vpool, pool);
--- End Message ---
--- End Message ---
