Bug 54030 - Support subjectAltName when (reverse-)proxying
Summary: Support subjectAltName when (reverse-)proxying
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2012-10-19 21:40 UTC by Michael Weiser
Modified: 2016-03-16 20:15 UTC (History)
0 users

subjectAltName support for httpd-2.4.2 (3.26 KB, patch)
2012-10-19 21:41 UTC, Michael Weiser
Details | Diff
subjectAltName support for httpd-trunk-20121019 (3.68 KB, patch)
2012-10-19 21:41 UTC, Michael Weiser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weiser 2012-10-19 21:40:42 UTC
A reverse proxy with SSLProxyCheckPeerCN turned on does not support certificates with subjectAltName:DNS extensions as of 2.4.3 and latest trunk. The attached patches seem to make that work for 2.4.2 and trunk. trunk already has some limited wildcard matching which is superseded by this patch. There is some mild code duplication since the logic is stolen from modules/ssl/ssl_engine_init.c:ssl_check_public_cert().
Comment 1 Michael Weiser 2012-10-19 21:41:18 UTC
Created attachment 29499 [details]
subjectAltName support for httpd-2.4.2
Comment 2 Michael Weiser 2012-10-19 21:41:49 UTC
Created attachment 29500 [details]
subjectAltName support for httpd-trunk-20121019
Comment 3 Kaspar Brand 2012-10-31 07:33:09 UTC
See also bug 53006.

Some preliminary comments about the patch: we really want to avoid duplicating code from ssl_check_public_cert() - there should be a single check_ID(...) function instead (i.e. the code should be factored out to ssl_util_ssl.c, ideally).

In the following two log messages, there's a misconception about what a "DN" really is in the context of an X.509 certificate:

+                ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c, APLOGNO()
+                              "SSL Proxy: Failure to extract DNs from"
+                              " peer certificate."
+                              " Requested hostname: %s", 

                 ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c, APLOGNO(02005)
                               "SSL Proxy: Peer certificate CN mismatch:"
-                              " Certificate CN: %s Requested hostname: %s",
-                              hostname, hostname_note);
+                              " Requested hostname: %s."
+                              " Last DN checked: %s.",
+                              hostname_note, id[i-1]);

DN is short for "distinguished name" (not "domain name"), and a certificate only has a single subject DN and a single issuer DN (for host name checks, the former is relevant).

Right now the name of the directive is "SSLProxyCheckPeerCN", so the code is currently doing what the documentation states ("Whether to check the remote server certificates CN field"). I agree that checking against subjectAltName entries is highly desirable (in the spirit of RFC 6125), but we might want to introduce a separate directive for this purpose (and deprecate SSLProxyCheckPeerCN).
Comment 4 Michael Weiser 2012-10-31 18:22:37 UTC
Complete agreement. To be clear: Are you inclinded (and have the time) to implement those changes yourself or are you challenging me to update the patch? If the latter: I can certainly try the refactoring and terminology cleanup but feel ill equipped to add a config option because of all the further infrastructure knowledge required for that.
Comment 5 Kaspar Brand 2012-11-05 06:28:48 UTC
(In reply to comment #4)
> Are you inclinded (and have the time) to implement those changes yourself

Not within a short-term timeframe (say, this month), but mid-term, yes.
Comment 6 Kaspar Brand 2012-12-26 11:01:13 UTC
I have implemented this in trunk with r1425874 - testing would be appreciated.
Comment 7 Michael Weiser 2013-01-09 16:06:15 UTC
Sorry for the sluggish response. I've tested and it seems to work nicely with current head. Thanks!

Can this be backported to 2.4?
Comment 8 Kaspar Brand 2013-01-16 06:44:58 UTC
(In reply to comment #7)
> Can this be backported to 2.4?

Yes, proposed for 2.4 with r1433834.
Comment 9 Yann Ylavic 2016-03-16 20:15:33 UTC
Backported to 2.4.5 in r1485667.