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

RESOLVED FIXED

Status

Infrastructure & Operations
WebOps: SSL and Domain Names
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: justdave, Assigned: atoll)

Tracking

(Blocks: 1 bug)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/962] )

Attachments

(2 attachments)

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!

Updated

2 years ago
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/962]
Blocks: 1155526
(Assignee)

Comment 1

2 years ago
Emailed Digicert asking if we can upgrade this to a SAN certificate, since it's a 3-year expiry.
Flags: needinfo?(rsoderberg)

Updated

2 years ago
Assignee: server-ops-webops → rsoderberg
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...
(Assignee)

Comment 3

2 years ago
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.
Flags: needinfo?(rsoderberg) → needinfo?(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.
Flags: needinfo?(justdave)
(Assignee)

Comment 5

2 years ago
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.

Updated

2 years ago
No longer blocks: 968636

Comment 6

2 years ago
No longer blocking decommissioning of bzr.m.o; adding directly to the bugzilla infra tracker.
Blocks: 1112437
No longer blocks: 967642
(Assignee)

Comment 7

2 years ago
Order #00674058 to replace Order #0045154, waiting for Digicert to issue.
(Assignee)

Comment 8

2 years ago
Created attachment 8598392 [details]
Intermediate (chained root) certificate

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

Comment 9

2 years ago
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.
(Assignee)

Comment 10

2 years ago
Apologies for the delays here - please reopen if you encounter any issues.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
key and cert deployed.  the intermediate matches the one we already had.  Looks good!

Thanks!

Comment 12

2 years ago
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

2 years ago
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
(Assignee)

Comment 14

2 years ago
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

2 years ago
(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 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.
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
(Assignee)

Comment 18

2 years ago
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.
You need to log in before you can comment on or make changes to this bug.