Bug 56353 - SNI not working correctly when certificate is defined in global scope
Summary: SNI not working correctly when certificate is defined in global scope
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.9
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2014-04-06 11:44 UTC by hanno
Modified: 2014-08-18 07:50 UTC (History)
0 users



Attachments
Reverse apr_array_append order with cfgMergeArray (621 bytes, patch)
2014-04-07 04:38 UTC, Kaspar Brand
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description hanno 2014-04-06 11:44:06 UTC
I found a regression but in the behaviour certificates get loaded in apache 2.4.9. The same issue does not appear in 2.4.7 and is therefore a regression.

When one defines a certificate in the global scope (outside any VirtualHost), all hosts deliver that certificate.

Example config:

SSLCertificateFile /etc/apache2/certs/test1.crt
SSLCertificateKeyFile /etc/apache2/certs/test1.key
<VirtualHost *:443>
        ServerName test1.local
        DocumentRoot /var/www/test1/
        SSLEngine On
</VirtualHost>
<VirtualHost *:443>
        ServerName test2.local
        DocumentRoot /var/www/test2/
        SSLEngine On
        SSLCertificateFile /etc/apache2/certs/test2.crt
        SSLCertificateKeyFile /etc/apache2/certs/test2.key
</VirtualHost>

What should happen: The first vhost (test1.local) should deliver test1.crt and the second host (test2.local) should deliver test2.crt.
However, what happens is that both hosts deliver test1.crt.

It gets even weirder when one adds certificate chains. They still get delivered by vhosts. So if I e.g. add a certificate chain to test2.local in this example, I'll get test1.crt with the chain defined in test2.local.
Comment 1 Kaspar Brand 2014-04-07 04:38:20 UTC
Created attachment 31485 [details]
Reverse apr_array_append order with cfgMergeArray

(In reply to hanno from comment #0)
> When one defines a certificate in the global scope (outside any
> VirtualHost), all hosts deliver that certificate.

True, I can confirm (I realized this when looking into bug 56306).

Can you try the attached patch with 2.4.9 and let us know if it addresses your issue?

> It gets even weirder when one adds certificate chains. They still get
> delivered by vhosts. So if I e.g. add a certificate chain to test2.local in
> this example, I'll get test1.crt with the chain defined in test2.local.

What version of OpenSSL are you using, and how exactly do you "add a certificate chain" - with SSLCertificateChainFile, or by including it in the file pointed to by SSLCertificateFile?

(Note that for an SNI setup, it doesn't make much sense to have global-level SSLCertificate[Key]File settings - the default cert should simply go into the first VirtualHost block.)
Comment 2 hanno 2014-04-07 04:46:29 UTC
(In reply to Kaspar Brand from comment #1)
> Created attachment 31485 [details]
> Reverse apr_array_append order with cfgMergeArray
[...]
> Can you try the attached patch with 2.4.9 and let us know if it addresses
> your issue?

Yeah, patch fixes it, everything seems back to normal. Will re-test with my real server setup, but local tests seem fine.

> > It gets even weirder when one adds certificate chains. They still get
> > delivered by vhosts. So if I e.g. add a certificate chain to test2.local in
> > this example, I'll get test1.crt with the chain defined in test2.local.
> 
> What version of OpenSSL are you using, and how exactly do you "add a
> certificate chain" - with SSLCertificateChainFile, or by including it in the
> file pointed to by SSLCertificateFile?

With SSLCertificateChainFile and openssl 1.0.1f.
(I'm aware that 2.4.9 warns it is considered deprecated. I'm not happy with that, but this is outside the scope of this bug report, I may comment on that on the dev ml)

> (Note that for an SNI setup, it doesn't make much sense to have global-level
> SSLCertificate[Key]File settings - the default cert should simply go into
> the first VirtualHost block.)

No, that doesn't work. If I set no global cert and have vhosts without their own cert apache simply won't start. (log says "SSL Library Error: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate assigned")
Comment 3 Kaspar Brand 2014-04-09 10:00:12 UTC
(In reply to hanno from comment #2)
> Yeah, patch fixes it, everything seems back to normal. Will re-test with my
> real server setup, but local tests seem fine.

Thanks for testing/confirming. I have committed this to trunk with r1585918 and proposed for backport to 2.4.x in r1585922.

> > (Note that for an SNI setup, it doesn't make much sense to have global-level
> > SSLCertificate[Key]File settings - the default cert should simply go into
> > the first VirtualHost block.)
> 
> No, that doesn't work. If I set no global cert and have vhosts without their
> own cert apache simply won't start. (log says "SSL Library Error:
> error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate
> assigned")

It's not yet clear to me what the use for this is - SNI is mostly about configuring an individual cert for each VirtualHost (not multiple vhosts sharing the same cert), so I wonder why you need globally configured "fallback" SSLCertificate[Key]File directives. Can you perhaps give more details on the rationale for such a setup?
Comment 4 hanno 2014-04-11 15:31:22 UTC
> Can you perhaps give more details on the rationale for such a setup?

I thought it's pretty obvious, but I can give you some details:

We have a server running with a default wildcard-certificate for *.schokokeks.org. So basically first we have a number of vhosts that share this certificate (config.schokokeks.org, webmail.schokokeks.org etc) and don't need any SNI at all.

Then we have a large number of customer vhosts on other domains. Some of those have their own certificate, so it gets added to the vhost via SNI. But obviously, not everyone gets his own certificate, so there are also a number of domains that don't have a valid certificate at all. However, we still make these hosts available through https, so the customers can add exceptions to their browser if they want to privately access the page via https.

I could obviously add the default certificate to every vhost that doesn't have its own. But this would blow up the configuration a lot for no gain and adds unneccesarry complexity.
Comment 5 Kaspar Brand 2014-04-16 08:09:15 UTC
Hanno, I have attached a more thorough fix for merging global and per-vhost settings to bug 56306 (attachment 31531 [details]). Would appreciate if you could give it a try and let me know if it's working for your setup as well.
Comment 6 Kaspar Brand 2014-04-18 08:40:32 UTC
(In reply to Kaspar Brand from comment #3)
> and proposed for backport to 2.4.x in r1585922.

Committed to 2.4.x with r1588245. To appear in 2.4.10.
Comment 7 Christophe JAILLET 2014-08-18 07:50:02 UTC
Fixed and released in 2.4.10