1155525 - SAN SSL certificate for bzr.bugzilla.org; lists.bugzilla.org

Status: RESOLVED FIXED

(Infrastructure & Operations :: SSL Certificates, task)

Description

[Dave Miller [:justdave]]

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!

Comment 1

[:Atoll]

Emailed Digicert asking if we can upgrade this to a SAN certificate, since it's a 3-year expiry.

Comment 2

[Dave Miller [:justdave]]

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...

Comment 3

[:Atoll]

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.

Comment 4

[Dave Miller [:justdave]]

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.

Comment 5

[:Atoll]

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.

Comment 6

[Mark Côté [:mcote]]

No longer blocking decommissioning of bzr.m.o; adding directly to the bugzilla infra tracker.

Comment 7

[:Atoll]

Order #00674058 to replace Order #0045154, waiting for Digicert to issue.

Comment 8

[:Atoll]

Attachment: Intermediate (chained root) certificate

This chained root must be installed alongside the signed server certificate for it to validate.

Comment 9

[:Atoll]

Attachment: 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.

Comment 10

[:Atoll]

Apologies for the delays here - please reopen if you encounter any issues.

Comment 11

[Dave Miller [:justdave]]

key and cert deployed.  the intermediate matches the one we already had.  Looks good!

Thanks!

Comment 12

[Frédéric Buclin]

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'

Comment 13

[Frédéric Buclin]

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

Comment 14

[:Atoll]

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

?

Comment 15

[Frédéric Buclin]

(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.

Comment 16

[Shyam Mani [:fox2mike]]

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 63.245.223.42: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.

Comment 17

[Gervase Markham [:gerv]]

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

Comment 18

[:Atoll]

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.