On 3/3/21 11:01 AM, Stefan Eissing wrote:
>
>
>> Am 03.03.2021 um 10:44 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>>
>>
>>
>>> Am 03.03.2021 um 10:31 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>
>>>
>>>
>>> On 3/3/21 9:54 AM, Stefan Eissing wrote:
>>>>> Am 03.03.2021 um 09:35 schrieb Stefan Eissing
>>>>> <stefan.eiss...@greenbytes.de>:
>>>>>
>>>>>
>>>>>
>>>>>> Am 02.03.2021 um 20:54 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/2/21 3:21 PM, ic...@apache.org wrote:
>>>>>>> Author: icing
>>>>>>> Date: Tue Mar 2 14:21:18 2021
>>>>>>> New Revision: 1887085
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=1887085&view=rev
>>>>>>> Log:
>>>>>>> Adding more ap_ssl_* functions and hooks to the core server.
>>>>>>>
>>>>>>> - ap_ssl_add_cert_files() to enable other modules like mod_md to
>>>>>>> provide
>>>>>>> certificate and keys for an SSL module like mod_ssl.
>>>>>>> - ap_ssl_add_fallback_cert_files() to enable other modules like mod_md
>>>>>>> to
>>>>>>> provide a fallback certificate in case no 'proper' certificate is
>>>>>>> available for an SSL module like mod_ssl.
>>>>>>> - ap_ssl_answer_challenge() to enable other modules like mod_md to
>>>>>>> provide a certificate as used in the RFC 8555 'tls-alpn-01' challenge
>>>>>>> for the ACME protocol for an SSL module like mod_ssl.
>>>>>>> - Hooks for 'ssl_add_cert_files', 'ssl_add_fallback_cert_files' and
>>>>>>> 'ssl_answer_challenge' where modules like mod_md can provide providers
>>>>>>> to the above mentioned functions.
>>>>>>>
>>>>>>>
>>>>>>> Modified:
>>>>>>> httpd/httpd/trunk/CHANGES
>>>>>>> httpd/httpd/trunk/include/ap_mmn.h
>>>>>>> httpd/httpd/trunk/include/http_protocol.h
>>>>>>> httpd/httpd/trunk/modules/md/mod_md.c
>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>>>>>>> httpd/httpd/trunk/modules/ssl/ssl_private.h
>>>>>>> httpd/httpd/trunk/server/protocol.c
>>>>>>>
>>>>>>
>>>>>>> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>>>>>>> URL:
>>>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1887085&r1=1887084&r2=1887085&view=diff
>>>>>>> ==============================================================================
>>>>>>> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
>>>>>>> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Tue Mar 2
>>>>>>> 14:21:18 2021
>>>>>>> @@ -2316,11 +2316,29 @@ void ssl_callback_Info(const SSL *ssl, i
>>>>>>> #ifdef HAVE_TLSEXT
>>>>>>>
>>>>>>> static apr_status_t set_challenge_creds(conn_rec *c, const char
>>>>>>> *servername,
>>>>>>> - SSL *ssl, X509 *cert, EVP_PKEY
>>>>>>> *key)
>>>>>>> + SSL *ssl, X509 *cert, EVP_PKEY
>>>>>>> *key,
>>>>>>> + const char *cert_file, const
>>>>>>> char *key_file)
>>>>>>> {
>>>>>>> SSLConnRec *sslcon = myConnConfig(c);
>>>>>>>
>>>>>>> sslcon->service_unavailable = 1;
>>>>>>> + if (cert_file) {
>>>>>>> + if (SSL_use_certificate_chain_file(ssl, cert_file) < 1) {
>>>>>>
>>>>>> As noted by the failure of build #1461 (
>>>>>> https://travis-ci.com/github/apache/httpd/jobs/487481449)
>>>>>> SSL_use_certificate_chain_file is not available with OpenSSL 1.0.2 which
>>>>>> is still the OS
>>>>>> provided standard version with Ubuntu 16 LTS and RedHat / Centos 7.
>>>>>
>>>>> Is there a known alternative?
>>>>
>>>> Will use SSL_use_certificate_file() there which is available in 1.0.2.
>>>
>>> Two questions:
>>>
>>> 1. Do SSL_use_certificate_file and SSL_use_certificate_chain_file do the
>>> same thing? My understanding of the documentation is that
>>> SSL_use_certificate_chain_file loads a certificate chain (and just a
>>> chain) from the file while SSL_use_certificate_file loads
>>> just a certificate.
>>
>> In my testing, they both do the same when the file contains only a
>> self-signed certificate. Which is the use case with ACME.
>>
>> But you are correct, as the documentation says
>> "SSL_CTX_use_certificate_file() loads the first certificate stored in file
>> into ctx.". And "SSL_CTX_use_certificate_chain_file" loads a complete chain,
>> starting with the client/server certificate.#
>>
>> So, ideally, we'd want to call SSL_use_certificate_chain_file(), because it
>> is more flexible. The ACME use case can live with the less potent call
>> available in 1.0.2.
>>
>> Maybe we should "#if version >= 1.1" and use the better one then?
>>
>>>
>>> 2. Is it a good idea that consumers of the ssl_answer_challenge hook can
>>> only provide certs and keys via files? What if these are
>>> not stored in a file? Would it be an option to have the hook return a
>>> **void for the cert and a **void for the key in addition
>>> that can be NULL or that in the OpenSSL case contain a **X509 and
>>> **EVP_PKEY?
>>
>> I was thinking about that. But imagine a scenario where a server has 2 SSL
>> modules loaded. What would the "void*" be for? How could a module given a
>> value in it know it's safe to use?
>>
>> Besides PEM files, the only other portable way I can think of are DER bytes.
>>
>> I opted for files, since those do exists in the mod_md ACME case already and
>> so it was easy to do. Not the best design criteria, but not the worst either.
>>
>> - Stefan
>
> Good that there is Rüdiger!
>
> Thinking about this: how much work would it be for mod_ssl to accept PEM
> bytes? That would make the exchange of certificate independent of the file
> system and portable.
I guess PEM_read_bio_X509 / PEM_read_bio_RSAPrivateKey could do the job with a
BIO created via BIO_new_mem_buf.
>
> typedef struct ap_bytes ap_bytes;
> struct {
> const char *data;
> apr_size_t len;
> } ap_bytes;
>
> AP_DECLARE(int) ap_ssl_answer_challenge(conn_rec *c, const char *server_name,
> const ap_bytes **pcertificate_key_pem);
Crossing posts :-). Quick questions:
1. What is the need for the len field above? I think PEM encoded data could be
nul terminated. Or do you want to leave an option
for DER data?
2. As there is only one ap_bytes ** above, do you want to merge the PEM encoded
certificate and key in one string?
Regards
Rüdiger
