We have an existing SSL certificate for lists.bugzilla.org. bzr.bugzilla.org now lives on the same server with it, and being unsure whether the bzr client can do SNI or not, it's safer to go with a SAN certificate that works with both domains. The key we're using was originally generated by webops and placed into puppet for mailman4.mail.corp.phx1.mozilla.com. If it still exists, feel free to use that to generate the new csr/certificate. If not, I don't mind installing a new key. Thanks!
Emailed Digicert asking if we can upgrade this to a SAN certificate, since it's a 3-year expiry.
Been checking through docs, and as of bzr version 2.5, it does support SNI, so we could do separate certs. Versions of bzr prior to 2.5 didn't support SNI but also didn't bother to validate the SSL cert, so they won't care anyway. On the other hand, if Digicert will let you upgrade the existing cert that would likely be cheaper than getting a new one...
If you make the bzr cert the primary cert on the server, and use SNI for lists.bugzilla.org, then that would serve your needs as well (and we wouldn't need to issue any new certs, so no additional cost at all), since the browsers all support SNI and bzr wouldn't need to. It sounds like we can do SNI here, with the existing separate certs, and reissuing the bzr cert will change its fingerprint (which is a hassle for users), so I'm voting for the SNI strategy here. If that's acceptable, you can RESO WFM this bug; otherwise, let me know and I'll proceed with issuing a new SAN cert and coordinate a swap with you so we can issue a refund.
Except that we don't have a cert for bzr.bugzilla.org at all, so we'd still need to purchase a cert for that. So we do need one of two things, either 1) A new cert for bzr.bugzilla.org by itself, or 2) a SAN cert that includes both domain names.
Ooh. Hm. You're right, I searched for the wrong domain, I'm sorry. Okay. A SAN cert will be *slightly* (~$20) more expensive for 2 domains, but comes with 4 slots in case you think there will be further domains hosted on this server someday. That cost is fine for us if you think it best,a nd it sounds like SNI adds unneeded complexity here, so I'm inclined towards SAN and will proceed tomorrow with that.
No longer blocking decommissioning of bzr.m.o; adding directly to the bugzilla infra tracker.
Order #00674058 to replace Order #0045154, waiting for Digicert to issue.
Created attachment 8598392 [details] Intermediate (chained root) certificate This chained root must be installed alongside the signed server certificate for it to validate.
Created attachment 8598393 [details] Signed server certificate This certificate, along with its intermediate in attachment 8598392 [details], is associated with the .key file at the usual root-ca location.
Apologies for the delays here - please reopen if you encounter any issues.
key and cert deployed. the intermediate matches the one we already had. Looks good! Thanks!
I still get: # bzr pull --remember https://bzr.bugzilla.org/bugzilla/trunk bzr: ERROR: Certificate error: hostname 'bzr.bugzilla.org' doesn't match 'lists.bugzilla.org'
And even if I use http instead of https, I get: # bzr pull --remember http://bzr.bugzilla.org/bugzilla/trunk http://bzr.bugzilla.org/bugzilla/trunk is permanently redirected to http://bzr.bugzilla.org/bugzilla/trunk/ bzr: ERROR: Cannot lock LockDir(filtered-46246096:///bugzilla/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
What version of bzr are you using? If you open https://bzr.bugzilla.org in a browser on that same computer, and view the certificate details, does it show: commonName bzr.bugzilla.org serialNumber 02 05 FC 70 86 05 27 D7 9E 9D AF 52 03 53 61 41 ?
(In reply to Richard Soderberg [:atoll] from comment #14) > What version of bzr are you using? bzr --version Bazaar (bzr) 2.6.0 > commonName bzr.bugzilla.org > serialNumber 02 05 FC 70 86 05 27 D7 9E 9D AF 52 03 53 61 41 Yes, I see that too.
This could be because of SNI and the bzr client failing on SNI. Note the difference between the following : shyam@katniss ~ $ openssl s_client -connect bzr.bugzilla.org:443 --- Certificate chain 0 s:/C=US/ST=CA/L=Mountain View/O=Mozilla Foundation/CN=lists.bugzilla.org i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA 1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- and shyam@katniss ~ $ openssl s_client -connect 18.104.22.168:443 -servername bzr.bugzilla.org --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Mozilla Foundation/CN=bzr.bugzilla.org i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA 1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- So if this is a requirement, then we'll need to issue a new SSL certificate I guess.
We can either issue a new SSL cert, or we can tell people to pass "-Ossl.cert_reqs=none" to bzr, which suppresses checking. Given that people are (hopefully) only using this server as a crutch to enable them to make the switch to git, that might be OK. But if we are going to get the cert redone, can we get it done? :-) It's been 3 months... Gerv
We are not planning to redo this cert. SNI was added in TLS 1.0. Any client that doesn't support it will need to use the workaround. I assume later versions of bzr repair SNI support. However as this server is, as you state, "a crutch to enable them to make the switch to git", this is an acceptable state of affairs for the server to operate in.