Last modified: 2014-02-04 21:48:56 UTC
Cert chain is missing intermediate cert.
To be clear, this is not just about doing things right; the service inaccessible to some users (e.g. my phone) in its current state.
Also, should copy the nginx conf for cipher prefs, etc. from prod.
If this is still a problem, I'd say it's at least normal priority.
This still exists. I get the certificate error (intermediate missing) on my Android phone and Tablet. For me it causes tool breakage, as my tool depends on a CORS connection to labs, which is refused for hosts with broken certs.
I played around with it a bit yesterday, but any attempt appeared futile. On tools-webproxy, I made sure RapidSSL_CA.pem was in /etc/ssl/certs, up to date and had a symlink. I've set SSLCACertificatePath to /etc/ssl/certs, shut down and started up Apache, and still only the server certificate was served either to online test sites or "echo | openssl s_client -connect tools.wmflabs.org:443 | less". I set SSLCertificateChainFile to tools.wmflabs.org.chained.pem which I created by "cat tools.wmflabs.org.pem RapidSSL_CA.pem GeoTrust_Global_CA.pem > tools.wmflabs.org.chained.pem", yet: Nada. I've renamed tools.wmflabs.org.chained.pem to tools.wmflabs.org.pem to have Apache read the chained certificate as its only SSLCertificateFile option, and still only the server certificate was served; and in all cases, after a proper shutdown & start. So, Coren, after this experience and recently watching RobH fiddle with wikitech's certificate for hours to get it right, a checklist: "File x should have one -- CERTIFICATE -- session", "Directive y should point to file Z", etc. would be greatly appreciated :-).
I fixed this with step-by-step instructions from jeremyb, inspired by bug #23631: - Point SSLCertificateFile to tools.wmflabs.org.pem, and - point SSLCertificateChainFile to RapidSSL_CA.pem. Yeah, that's right, not to some chained certificate or whatever, just to the missing intermediate certificate :-). Thanks again to jeremyb for his help.
Wait, so SSLCertificateChainFile should specifically /not/ be a certificate chain file? That's... so sane. *groan* Thanks for debugging this Tim.
The error still keeps reoccurring intermittently. I've sent since sent two emails to the labs list. As soon as the bug was closed I tried it on my Android phone and it worked fine. A few hours later I tried it on my tablet and it didn't work. Early this morning it worked, and just now it failed again (this seems to be device independent and only depending on time). Could there be multiple hosts that need the fix (round robin)?
While http://www.sslshopper.com/ssl-checker.html#hostname=tools.wmflabs.org has an all green result http://www.sslshopper.com/ssl-checker.html#hostname=fastcci1.wmflabs.org gives a warning ("The certificate is not trusted in all web browsers.")
(In reply to comment #8) > The error still keeps reoccurring intermittently. I've sent since sent two > emails to the labs list. As soon as the bug was closed I tried it on my > Android > phone and it worked fine. A few hours later I tried it on my tablet and it > didn't work. Early this morning it worked, and just now it failed again (this > seems to be device independent and only depending on time). > Could there be multiple hosts that need the fix (round robin)? No, there is only one host (tools-webproxy) that handles SSL and then relays via plain http to tools-webserver-0[1-3]/tools-webgrid-01. I can't reproduce your problems; I've tried three online checks (http://www.sslshopper.com/ssl-checker.html, http://www.digicert.com/help/, https://www.ssllabs.com/ssltest/analyze.html) and all succeed (while they failed previously). Are you directly accessing https://tools.wmflabs.org/ (vs. CORS in your tool) and seeing the issue? Which phone/tablet and software are you using?
(In reply to comment #9) > While > http://www.sslshopper.com/ssl-checker.html#hostname=tools.wmflabs.org > has an all green result > http://www.sslshopper.com/ssl-checker.html#hostname=fastcci1.wmflabs.org > gives a warning ("The certificate is not trusted in all web browsers.") (That was a mid-air collision :-).) I fixed *only* tools.wmflabs.org (as per the title of this bug :-)). So I'm closing this bug again. I assume you use [[wikitech:Help:Proxy]] for fastcci1? Could you open another bug for that as it is a totally unrelated system?
*** Bug 58284 has been marked as a duplicate of this bug. ***
