After reading Heroku articles, Stack Overflow questions, and the Stripe payments integration guides, the general advice is that I should should purchase an SSL certificate for my custom domain that points to my Heroku app.
Can anyone offer an explanation or other resource to help me understand why I need an SSL certificate?
I understand that SSL encrypts transmitted data, but if Heroku provides SSL, then where am I lacking encryption?
Would a simple explanation be that http://example.com forwards all transmitted data to https://myapp.herokuapp.com, therefore someone could intercept that data on that “leg” of the DNS routing chain?
You pay a certificate authority (CA) to sign a certificate that certifies that a particular public key corresponds to a particular host name that you control.
You don’t need a signed certificate to achieve confidentiality between you and some destination server. You only need the public key of your intended communication partner.
The fundamentally hard problem that a signed certificate solves is not confidentiality but identity. Suppose a customer tries to talk to example.com. The customer connects to some server, and that server supplies a public key for confidential communication. If the key isn’t signed by a trusted authority, though, how do you know that the server you’re talking to is really example.com?
In order to get a signed certificate, you go to a certificate authority and supply a public key, a host name, and sufficient evidence that you are the operator of the host name. If the CA is satisfied with your evidence, they issue a signed certificate linking your public key to your host name, which anyone can verify. Based on that certificate, the user learns that the CA (whom the user already trusts) asserts a pairing between the received public key and the host name they are trying to talk to.
There’s no way for a user’s system to know that example.com and myapp.herokuapp.com are the same service. (Comparing IP addresses isn’t useful, because multiple sites may be hosted from the same IP, varying content by the Host request header.) The host names are different, so you need separate certification for each name.
It is possible for you to act as you own CA and produce a self-signed certificate. However, anyone can produce a self-signed certificate, so it doesn’t provide any identity proof. Your operating system has a list of trusted CAs, whom we generally trust to be discerning when signing certificates. When a user sees a certificate signed by a trusted CA, the user can be reasonably sure that the CA has done due diligence in verifying that the public key is the correct one for that domain.
3
This state of affairs (when you have to cough up for a cert) will not persist for long. There’s a very promising initiative Let’s Encrypt which will provide free certificates in an automatic mode. It is bound to launch in mid-2015. It is sponsored by Mozilla, EFF, Akamai, and Cisco. Thus, you’ll have the best of two worlds: a non-self-signed, identity-verified certificate that will at the very least work in Firefox, and a gratis, hassle-free one at that.
Identity verification will be based on the ACME protocol.
You can generate your own certificate, and it will work perfectly fine. The reason you buy one instead of making one is that certificates from well-known CA’s will not generate an error in the client browser indicating that the signing certificate authority is unknown and not trusted.
1