Heroku SSL added but visiting domain still says connection is not private - ssl

I use Heroku for deploying my app and I used GoDaddy to purchase my custom domain name and I purchased my SSL certificate from them.
Let's call my heroku hosted version of my application example-101.herokuapp.com
And let's call my custom domain I own mycustomdomain.com
I was trying to set up my GoDaddy purchased SSL certificate through heroku, and followed all of the steps here through step 7:
http://www.joshwright.com/tips/setup-a-godaddy-ssl-certificate-on-heroku
Everything appears to be set up well. When I look in my Heroku GUI, at my settings for example-101.herokuapp.com, under 'Custom Domains' it lists www.mycustomdomain.com and mycustomdomain.com, each with DNS target mycustomdomain.com.herokudns.com and www.mycustomdomain.com.herokudns.com respectively.
When I run in the terminal:
curl -kvI https://www.mycustomdomain.com
the output says it "Connected", it "successfully set certificate verify locations", and after all the handshakes it says "SSL certificate verify ok."
Now, here is where I'm afraid my problem may be.
In GoDaddy, under my DNS Management for mycustomdomain.com, I followed heroku instructions by creating a new record as follows:
Type: CNAME
Name: www
Value: example-101.herokuapp.com
TTL: 1 hour
But this was based on documentation that doesn't take into regard adding an SSL certificate.
When I run
heroku certs
it gives me the following:
Name: brachiosaurus-94028
Common Names: www.mycustomdomain.com, mycustomdomain.com
Trusted: True
Type: SNI
Should I be referencing brachiosaurus-94028 anywhere?
When I actually try to visit www.mycustomdomain.com in my browser, the error it reads is NET::ERR_CERT_COMMON_NAME_INVALID , and in the details, it says the Subject is *.herokuapp.com
Is that the issue? That it's pointing to herokuapp.com when it should be pointing to herokussl.com or something of that nature?
If you have any insight on why this isn't working please let me know.
Also, I just set all of this up about an hour ago. Does it take a day or two before it it working properly and the browser recognizes the SSL certificate? Am I jumping the gun on asking for help?

I contacted the heroku support, my problem was fixed.
1, set your CNAME correctly(I used the namecheap domains)
2, after that, check that the heroku DNS target is the same as the namecheap host value.
3, restart the ACM (ssl)
4, you need to wait for several minutes to check the website.

Heroku has a new ssl implementation: https://devcenter.heroku.com/articles/ssl
The asker appears to be using this new implementation. For this implementation, it's required to set the CNAME in your DNS Management as mycustomdomain.com.herokudns.com. You do not need to reference your certificate name, brachiosaurus-94028 in your case.

When you add the SSL addon to Heroku, it generates a new domain, and you should use it as your CNAME value, and it's not the original herokuapp.com anymore. The heroku certs command should give you the domain you should use, which ending is herokussl.com
In your case, you probably should set the value of your CNAME as brachiosaurus-94028.herokussl.com (you can test the endpoint on your browser to see if it works).
It should not take so much time for it to work also (when I do this it is always instantly)
For more information check Heroku docs

In my case, this error was encountered because my DNS record specified app-name.herokuapp.com as the target for the CNAME rather than the provided DNS target. Update your DNS record to point at the correct DNS target.
To get the correct DNS target, run heroku domains in cli and it will show something like:
=== app-name Custom Domains
Domain Name DNS Record Type DNS Target
api.myapp.io CNAME powerful-tick-i29i319i39121321.herokudns.com

Related

Bit confused with cloudfront and why my cert for the CNAME is not working

I am getting this message on my main site, after I setup a CloudFront distribution. I created a certificate for cdn.example.com, chose custom and entered cdn.example.com for use with HTTPS.
I created a CNAME in my DNS configuration for cdn.example.com, and I added the validation record as requested by AWS. The certificate shows up as issued and validated.
Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “cdn.example.com”, which could put your confidential information at risk.
No images get loaded and the site does not render as it should. If I use the cloudfront url (i.e. d12345.cloudfront.net), all works fine. Do I need to add a SAN to my certificate, such as the main domain (i.e. example.com) in addition to cdn.example.com? If so, how does that work as I already use a SSL certificate for my www.example.com and example.com from Let's Encrypt.
I am using WordPress and wpfastestcache to integrate CloudFront with the website, where I specified cdn.example.com and the origin as example.com.
This question was confusing, since it seemed to describe a very unlikely condition. How could a newly-configured CloudFront distribution with a new certificate from ACM offer an invalid certificate?
In truth, I was distracted by part of the "helpful" browser error message, "You might be connecting to a server that is pretending to be..." I mistakenly assumed that this implied that the hostname in the certificate was correct ("pretending to be") but that the certificate was invalid for some other reason.
As it turns out, the certificate being offered was the default, generic *.cloudfront.net certificate, so the hostname in the cert didn't match the custom domain name.
After creating a certificate in ACM, it needs to be associated with the CloudFront distribution, as mentioned at https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesSSLCertificate.
Another hint to the nature of the problem would have been observable in the ACM console. There, the certificate would have shown In Use? No.
In Use? – Whether the ACM Certificate is actively associated with an AWS service such as Elastic Load Balancing or CloudFront. The value can be No or Yes.
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-list.html#gs-acm-list-console

DNS NXDOMAIN error command certbot

I'm trying to install a ssl certicate lets encrypt in my domain and my sub domaine.
I was sucessful installing the ssl certificate on my domain but i did't successful on my sub domain
I use the next command
certbot certonly --webroot -w /var/www/sub-domain/maxime-mazet.fr/owncloud/ -d cloud.maxime-mazet.fr
/var/www/sub-domain/maxime-mazet.fr/owncloud has the folder of my code.
cloud.maxime-mazet.fr is my sub domain.
my domain maxime-mazet.fr is host at ovh.
for cloud.maxime-mazet.fr I have created the enter A with the IP of server.
with my domain (maxime-mazet.fr) no error but with my sub domain (cloud.maxime-mazet.fr) the error is
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cloud.maxime-mazet.fr
Using the webroot path /var/www/sub-domain/maxime-mazet.fr/owncloud for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. cloud.maxime-mazet.fr (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for cloud.maxime-mazet.fr
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: cloud.maxime-mazet.fr
Type: connection
Detail: DNS problem: NXDOMAIN looking up A for
cloud.maxime-mazet.fr
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
The next pictures is my panel for the A of my domain and my sub domain
Thanks for your help
ns13.ovh.net and dns13.ovh.net do not appear to be authoritative for your domain name as they do not properly reply to queries on it. You will first need to solve that problem. Ask OVH if they are indeed the correct hosts to use for your domain. Since you seem to just have changed recently something on your domain name, you may just need to wait a little for things to settle.
Have a look at https://www.zonemaster.net/ to conduct tests on your zone. Until they are all ok do not play with Let's Encrypt.
I'm sorry for the screen but the ns13 and dns13 is good i have a new screen with all enter ;)

Accessing https sites with IP address [duplicate]

This question already has answers here:
Is it possible to have SSL certificate for IP address, not domain name? [closed]
(7 answers)
Closed 11 months ago.
I wonder why I am getting certificate error if I try to access a site with ip address instead of domain name. Lets say for example nslookup says google.com is 173.194.43.96, so I tried to browse https://173.194.43.96 and I got certificate error saying that the security certificate presented by this website was issued for a different website's address. Why is that so?
This is because an SSL certificate is issued for a particular domain name. If the certificate name doesn't match the visited domain, the browser will show an error.
One of the main functions of SSL is to prove to the user that they are really connecting to the site they requested, and not to an attacker masquerading as the end site. Without linking the domain name to the certificate this would not be possible.
It is conceivable that the browser certificate system could have been designed to include the IP address in the certificate, but this would make it difficult to use DNS load balancing or even to change hosting providers, as a new certificate would have to be issued each time this happened. If the certificate included just the IP address and not the domain, this would leave the user defenseless against DNS spoofing attacks. So the only way forward really was to use the domain alone.
As a matter of interest, it is possible to obtain an SSL certificate for an IP address - and as Google is their own certificate authority, they could issue themselves a certificate for 173.194.43.96 and thus make it possible to browse google securely by ip address, so long as they used SNI to serve up the correct certificate. It seems implausible that this would be worth the additional complexity however...
This is a nice introduction to SSL if you want to read more:
https://timnash.co.uk/guessing-ssl-questions/
On MAC High Sierra and Python 3.6.4, I tried the solution: requests toolbelt:HostHeaderSSLAdapter 1st, unfortunately, it doesn't work for me, then I tried
forcediphttpsadapter, got it works finally.
The author explains everything in the readme part and has provided a sample script and it can be followed easily.
1.Install the library by pip install requests[security] forcediphttpsadapter
2.run the sample script:
import requests
from forcediphttpsadapter.adapters import ForcedIPHTTPSAdapter
session = requests.Session()
session.mount("https://example.com", ForcedIPHTTPSAdapter(dest_ip='1.2.3.4'))
response = session.get(
'/some/path', headers={'Host': 'example.com'}, verify=False)
Note: For some cases, you may need to remove the prefix: 'www' from the url.
What happens is that the certificate is issued to www.google.com, and not to its IP address. Hence, your browser won't be able to verify the certificate, which lists www.google.com as entity.
For more info, see: www.digicert.com/ssl-support/certificate-name-mismatch-error.htm
The Common Name is typically composed of Host + Domain Name and will look like www.yoursite.com or yoursite.com. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain domain.com will receive a warning if accessing a site named www.domain.com or secure.domain.com, as www.domain.com and secure.domain.com are different from domain.com.

SSL - invalid CN after installing certificate (getting CN *.herokuapp.com)

I have a heroku app hosted at www.example.com.
I have a certificate issued for that address (www.example.com). I've installed the certificate successfully according to the heroku docs.
However, I how have a problem:
when I visit www.example.com, I get an invalid CN error (says that it is issued for *.herokuapp.com)
when I visit example.herokuapp.com, I also get an invalid CN error (this time the cert CN is for www.example.com)
So the certificates are pretty much flipped. This is still pretty fresh (<1 hour) - could waiting solve the problem?
Also: This part of the heroku docs shows an endpoint in the form example.herokussl.com
$ heroku certs:info
Fetching SSL Endpoint example-2121.herokussl.com info for example... done
And I'm getting the standard example.herokuapp.com endpoint, so I did not have to change the DNS settings after installing the certificate. Could that be some clue?
If you have already configured your domain DNS for non-SSL, standard http:// access, keep in mind that you need to update it again for SSL. From your Heroku account, go to your app settings, Domain section. You will see something like:
In this example, the example.com's DNS should be updated to point to example-ssl.herokussl.com (and not example-standard.herokuapp.com).
Turns out this was a DNS caching issue on my machine. Since this was Linux, changing browsers did not work (also for some reason restarting the dns deamon).
Anyway, it's fine now.

Heroku SSL Endpoint with purchased certificate does not seem to work

I have purchased an SSL certificate and installed it to my Heroku app.
However when I try to access my site via https, Chrome reports that:
The identity of this website has not been verified. • Server's
certificate does not match the URL.
Other browsers report a similar message.
Inspecting the certificate information in Chrome shows that my site is still using Heroku's certificate, issued by Digicert (instead of my own CA).
Any ideas as to what I could be missing?
The problem had to do with an incorrectly set DNS record.
As per the documentation (...), once the certificates are uploaded to Heroku, do:
heroku certs
This provides you the correct end point for the SSL enabled domain. This is a domain that looks like "tokyo-2121.herokussl.com".
Next, go to your DNS service provider and update/add the CNAMe record for the SSL enabled domain to point to "tokyo-2121.herokussl.com".