The following servers don't send the intermediate certificate: RapidSSL SHA256 CA - G3. It can be downloaded from http://gv.symcb.com/gv.crt.
[1] https://www.ssllabs.com/ssltest/analyze.html?d=rt.wikimedia.org
[2] https://www.ssllabs.com/ssltest/analyze.html?d=wikitech-static.wikimedia.org
[3] https://www.ssllabs.com/ssltest/analyze.html?d=etherpad.wikimedia.org
| Subject | Repo | Branch | Lines /- | |
|---|---|---|---|---|
| Provision the RapidSSL_SHA256_CA_-_G3 CA | operations/puppet | production | 40 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | RobH | T73156 Replace SHA1 certificates with SHA256 | |||
| Resolved | akosiaris | T88507 The certificate chains of newly installed SHA256 certificates are incomplete. |
This broke the RT mail gateway as evidenced in https://gerrit.wikimedia.org/r/#/c/188553/
Change 188562 had a related patch set uploaded (by Alexandros Kosiaris):
Provision the RapidSSL_SHA256_CA_-_G3 CA
Change 188562 merged by Alexandros Kosiaris:
Provision the RapidSSL_SHA256_CA_-_G3 CA
I managed to fix wikitech-static as well (albeit manually). Why does it even have HTTPS support btw ? Resolving
URGH, so even the replacement intermediary isnt really SHA256. I apologize, I should have caught this issue at the time of replacement!
I'll go through and point the right intermediary cert at the systems I've upgraded the rapidssl certs on, however the end result now is since the intermediary is still sha1 (for sha256 certs, nice rapidssl), we'll need to replace the certs outright in the long run.
it seems etherpad was fixed when rt was fixed (same system, and now pulling the cert with openssl shows proper intermediary.)
This is a myth. "RapidSSL SHA256 CA - G3" is definitely SHA256. The other intermediate is for compatibility with older clients such as XP/Server 2003 (but note that XP has root certificate update enabled by default).