On 10.06.2012 21:58, Stefan Fritsch wrote: > On Sunday 10 June 2012, Kaspar Brand wrote: >> As a matter of style / documentation "policy", I would prefer if >> the setup instructions in the reference documentation >> (mod_ssl.xml) are self-contained, i.e. people should not have to >> look at the FAQ to get this kind of information. >> >> Maybe we should also add a notice about SRP support only being >> available if compiled against OpenSSL 1.0.1 or later? > > done in r1348653
Comment in httpd-ssl.conf.in looks good, thanks. It was more the separation into mod_ssl.xml and ssl_faq.xml which I found a bit strange... or at least the fact that mod_ssl.xml doesn't say anything about using "openssl srp" to create the SSLSRPVerifierFile. > Unfortunately, ssl_log_ssl_error() doesn't log any error. Instead > openssl logs to stderr (newlines doubled by me for clarity): > > Sun Jun 10 21:21:46.051674 2012] [ssl:info] [pid 6734:tid 4148467456] > AH01914: Configuring server localhost:443 for SSL protocol > > wrong number of fields on line 1 (looking for field 6, got 1, '' left) > > [Sun Jun 10 21:21:46.051806 2012] [ssl:emerg] [pid 6734:tid > 4148467456] AH02308: Unable to load SRP verifier file [error 1] Ugh, the "wrong number of field" message is coming from an fprintf(stderr,...) in OpenSSL's crypto/txt_db/txt_db.c - apparently another piece which doesn't make use of the error queue. "[error 1]" on the other hand is mostly useless in its current form, I think. It's not mod_ssl's fault, but it should definitely be fixed in OpenSSL (whose SRP code should use some form of ERR_put_error() to return the SRP_ERR_* codes to the application). > I will trust you that SSL_CTRL_SET_TLS_EXT_SRP_USERNAME_CB will not > appear in 1.0.0 without full SRP support. The defines seem to be > rather haphazard: Most are named *_TLSEXT_* but some new ones are > *_TLS_EXT_*. The CTRLs were added to OpenSSL 1.0.1 (only) in http://cvs.openssl.org/chngview?cn=20500. They are not in 1.0.0, and according to http://www.openssl.org/support/faq.html#MISC8 never will be: > After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter > releases (e.g. 1.0.1a) can only contain bug and security fixes and no > new features. Minor releases change the last number (e.g. 1.0.2) and > can contain new features that retain binary compatibility. Changes to > the middle number are considered major releases and neither source nor > binary compatibility is guaranteed. > > Therefore the answer to the common question "when will feature X be > backported to OpenSSL 1.0.0/0.9.8?" is "never" but it could appear > in the next minor release. Kaspar
