[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 --- Comment #6 from Joe Orton --- FWIW I agree it's a bug this isn't caught by "httpd -t", but it would definitely not be acceptable to silently "disable" some vhosts because the certs were badly configured. Looks like it might require some significant surgery to fix, and there are various different ways certs can be configured, so doesn't look like a trivial patch at all. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 Andrew G. Watters changed: What|Removed |Added CC||and...@andrewwatters.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 --- Comment #5 from Andrew G. Watters --- This is still a bug as of 2022. I was panicking because I manage several websites, all of which are under one certificate and were down for 45 minutes while I troubleshooted. It would be really helpful if regular HTTP could start without HTTPS in the event of a mismatch. The cryptic startup error messages eventually led me to the ssl_error_log, which reported: AH02565: Certificate and private key fe80::3eec:efff:fefb:56d6:443:0 from /mnt/raid5/etc/ssl/andrewwatters_com.crt and /mnt/raid5/etc/ssl/andrewwatters_com.key do not match This apparently happens when the Certificate Signing Request uses the wrong key. To correct the CSR and use it with your existing key, do this: openssl req -new -key yourkey.key -out req.csr You'll have to fill out the required CSR fields, and you'll get a corrected CSR to use with your SSL provider. Hopefully they can promptly reissue the certificate or else you have a few days left on your prior certificate. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 Jaak Ristioja changed: What|Removed |Added CC||jaak+bz.apache.org@ristioja ||.ee -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 Andreas Schnederle-Wagner changed: What|Removed |Added CC||schnede...@futureweb.at -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 --- Comment #4 from Andreas Schnederle-Wagner --- This really odd behaviour just brought down one of our CMS Servers resulting in ~1.000 Websites being down for ~30 Minutes ... We rely on automated "configtest" before doing "reload" - it should NEVER happen that Apache refuses to start if neither configtest nor reload show any sign of Problem ... IMHO this should be handled with higher Priority than P2/normal ... -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 James Boylechanged: What|Removed |Added CC||un...@freeshell.org --- Comment #3 from James Boyle --- I've experienced this issue as well - I just want to share what I believe to be a common expectation among system administrators / DevOps folks out there. When a daemon fails to load, we expect the reason for the failure to be clearly logged, ideally to syslog. I agreed that the "Configuration Failed" (aka Apache initialization) and Apache returned "1" when it exited, but I hope everyone will admit the following two statements don't really give the administrator a good place to look for things to fix: "AH00016: Configuration Failed" ... and ... "Syntax OK" (from httpd -t) - which implies the configuration is OK I wish it had said something like: "AH00016: Configuration Failed: Security certificate error: /path/to/file" or "AH00016: Configuration Failed: VHost example.com: cannot initialize SSL/TLS" Thankfully I know about strace. Any solution that puts a message that points the administrator to the source of the problem is a win in my book. Thank you! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57360] Fail gracefully on certificate/key mismatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360 --- Comment #2 from Michael Herold--- I only proposed 1. and 2. since I thought 3. might be complicated. However, all the tools required to do the necessary checks at configtest are in place. Currently, the certificate/key checks are done in ssl_init_server_certs which is called as post config hook (ap_hook_post_config). Probably, moving one part of this code to a check config hook (ap_hook_check_config) would solve the problem. However, the support of encrypted private keys makes this task non-trivial (at least for me). I would have to investigation further to see if this a real problem. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org