[Bug 57360] Fail gracefully on certificate/key mismatch

2023-01-06 Thread bugzilla
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

2023-01-05 Thread bugzilla
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

2023-01-05 Thread bugzilla
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

2020-05-01 Thread bugzilla
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

2019-09-20 Thread bugzilla
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

2019-09-20 Thread bugzilla
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

2017-03-30 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57360

James Boyle  changed:

   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

2015-11-25 Thread bugzilla
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