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