Closed Bug 1162805 Opened 10 years ago Closed 10 years ago

Subdomain registration and SSL certificate: pontoon.allizom.org

Categories

(Infrastructure & Operations :: SSL Certificates, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: osmose, Unassigned)

Details

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

I've got a Heroku-hosted app at http://mozilla-pontoon-staging.herokuapp.com/ that I'd like to be accessible at https://pontoon.allizom.org. From what I read we need a CNAME entry added that points pontoon.allizom.org to mozilla-pontoon-staging.herokuapp.com, and then we need to purchase a cert and upload it to Heroku to enable SSL (and then there's some app changes to ensure the herokuapp.com URL redirects properly and to force SSL). I think I can handle uploading the certificate and private key to Heroku, as well as the app-side changes. Can we have the CNAME added and cert purchased and shared? Thanks!
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1132]
Once the cutover has happened, is it the case that the old pontoon staging site should be decommissioned?
I think the answer to that is yes, but mathjazz will know for sure if we should keep it around. In fact, I wasn't even aware of pontoon-dev.allizom.org, so maybe we should just reuse the cert for that and use that domain instead? Thoughts, mathjazz?
Flags: needinfo?(m)
Yes, the old Pontoon staging site should be decommissioned on the long term, but we'd like to keep the VM for now in case Heroku turns out to be inappropriate. Let's simply reuse pontoon-dev.allizom.org domain and it’s certificate and just point it to heroku-hosted stage.
Flags: needinfo?(m)
:ulfr, does Heroku permit us (IT Webops) to upload the *.allizom wildcart to Heroku and make it available for use by Mozilla folks in a safe fashion?
Flags: needinfo?(jvehent)
To update the bug on the Webops discussion here - we're trying to identify whether we need to issue individual SSL certs for every Heroku dev/stage site that would use *.allizom, or if we can (somehow) provision the *.allizom certificate to Heroku and make it available for use. Our goal is to do the latter, if we can find a safe way to do so. More soon once we hear from Opsec.
:atoll, we'll need to get access to Heroku to explore * if they allow sharing of wildcard certs between sites * if users can obtain the private key from a certificate once it's been uploaded * if they use ELBs for serving SSL connections or something else We'll also want to find out from Heroku how they store and keep save the cert private keys.
Flags: needinfo?(jvehent)
(In reply to Gene Wood [:gene] from comment #6) > :atoll, we'll need to get access to Heroku to explore > * if they allow sharing of wildcard certs between sites > * if users can obtain the private key from a certificate once it's been > uploaded > * if they use ELBs for serving SSL connections or something else > > We'll also want to find out from Heroku how they store and keep save the > cert private keys. Gene/Julien, If you guys can make accounts at heroku.com, :lonnen can give you access to the Mozilla Corp account.
(In reply to Gene Wood [:gene] from comment #6) > :atoll, we'll need to get access to Heroku to explore > * if they allow sharing of wildcard certs between sites > * if users can obtain the private key from a certificate once it's been > uploaded > * if they use ELBs for serving SSL connections or something else > > We'll also want to find out from Heroku how they store and keep save the > cert private keys. Along with the access granted by :fox2mike, you may be able to answer those questions by emailing Heroku support cc: opsec@, since that would be useful information to have alongside your investigations.
I created a free heroku account with jvehent@mozilla.com. Please grant me access.
(In reply to Julien Vehent [:ulfr] (use needinfo) from comment #9) > I created a free heroku account with jvehent@mozilla.com. Please grant me > access. Lonnen, can you add Julien to the Mozilla Corp heroku account please? Thanks!
Flags: needinfo?(chris.lonnen)
access granted. :ulfr I also set you up with permissions on the pontoon apps
Flags: needinfo?(chris.lonnen)
Any progress on this? Can we do a non-wildcard?
For staging envs, it may be easier to rely on the https://*.herokuapp.com cert. To my knowledge any cert we used would be accessible to any developer that works on the app, which is probably not acceptable for a wildcard. For production sites we can set up individual subdomain certs.
(In reply to Chris Lonnen :lonnen from comment #13) > For staging envs, it may be easier to rely on the https://*.herokuapp.com > cert. To my knowledge any cert we used would be accessible to any developer > that works on the app, which is probably not acceptable for a wildcard. For > production sites we can set up individual subdomain certs. Per comment 0, they are already using that today. :ulfr is out on PTO for several weeks, so we haven't heard back on how Heroku handles this yet from him - but by this comment, we simply cannot provide the *.allizom certificate for this purpose. So, we'd have to pay to issue a dedicated certificate for the non-production site, which is generally something we try to avoid where possible. So, unless someone specifically thinks that we should spend money on a real SSL certificate (what cost center is pontoon?) for the non-production app, we're likely to deny the request for the pontoon.allizom.org SSL certificate. I'll leave this bug open for a bit longer for discussion purposes, or in case someone considers this worth it.
That's fine by me. Confirming to our normal staging environment URL scheme ain't worth cash money. :D I'll just take back my request for the cert and call this bug closed, although if there was a way for Heroku to dole out wildcard certs the way we want in the future that'd be cool.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.