Today, when trying to login using the Lock widget the attempt is blocked by both Chrome and Safari (Chrome: “Your connection is not private”). This has been working for many months. The reason for the error is that the wrong certificate is presented from my-app-name.eu.auth0.com. Here are the certificate details: ![alt text][1]
It seems like something has gone wrong at Auth0 or GoDaddy, perhaps when rotating certificates. Any ideas about how to resolve this?
UPDATE:
Output of curl -iv https://[my-account].eu.auth0.com/test:
* Rebuilt URL to: https://[my-account].eu.auth0.com/
* Trying 52.58.175.29...
* TCP_NODELAY set
* Connected to [my-account].eu.auth0.com (52.58.175.29) port 443 (#0)
* SSL certificate problem: Invalid certificate chain
* Curl_http_done: called premature == 1
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
That’s not the expected certificate for a *.eu.auth0.com account. It seems something in that specific machine is forcing a request to [your_account].eu.auth0.com to be redirected/intercepted and then responded from an endpoint that is presenting a certificate that does not match. In general, this situation is highly suspicious so if you did not do any explicit steps to have some type of interception mechanism that would explain this behavior then I would consider that part of some malicious activity.
Do you only get the certificate issue when accessing https://[your_account].eu.auth0.com or do you get similar issues when accessing other HTTPS sites? For example, what happens if you access https://jwt.io? Can you also share the output of the following command: nslookup [your_account].eu.auth0.com?
UPDATE:
The IP address mentioned in the output of the curl command is no longer associated with accounts at *.eu.auth0.com. However, a quick online check shows that the IP in question is associated with the same cloud infrastructure provider used by Auth0 so the IP may at some point be associated with Auth0. However, these IP’s can change so ensure that you have nothing in your machine that hardcoded the IP address used at a certain point in time. You can see the IP addresses that are currently associated with your Auth0 account in the output of the nslookup command.
All other HTTPS sites I’ve tried are behaving normally, incuding https://jwt.io/ It only occurs on https://[my_account].eu.auth0.com and the first time I encountered it was today. For months it’s been working perfectly.
Here is the output from nslookup:
$ nslookup [my_account].eu.auth0.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: [my_account].eu.auth0.com
Address: 52.59.97.214
Name: [my_account].eu.auth0.com
Address: 54.93.108.42
All other HTTPS sites I’ve tried are behaving normally, incuding https://jwt.io/ It only occurs on https://[my_account].eu.auth0.com and the first time I encountered it was today. For months it’s been working perfectly.
Here is the output from nslookup:
$ nslookup [my_account].eu.auth0.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: [my_account].eu.auth0.com
Address: 52.59.97.214
Name: [my_account].eu.auth0.com
Address: 54.93.108.42
Thanks for the additional information, can you also try to visit each of the following sites and report the outcome: https://ephemeral.eu.auth0.com/test and https://ephemeral.auth0.com/test
They seem to be working fine:
https://ephemeral.eu.auth0.com/test
{“clock”:1499685160185}
https://ephemeral.auth0.com/test
{“clock”:1499685163170}
They seem to be working fine:
https://ephemeral.eu.auth0.com/test
{“clock”:1499685160185}
https://ephemeral.auth0.com/test
{“clock”:1499685163170}
And if you use the /test endpoint with your account https://[your_account].eu.auth0.com/test it triggers the previous certificate issue, correct?
Apologies for the back and forward, but since I’m unable to reproduce this on my end, even when testing against what I believe is the account where you mention the problems, the name starts with m, I have one more request. What’s the output of curl -iv https://[your_account].eu.auth0.com/test?
You can redact the sensitive parts and update the question with the full output as it will likely exceed what’s allowed in a comment.
I updated the answer to take in consideration the curl command output. Your machine is sending the request to the incorrect IP address, you may have hardcoded this IP address at a certain point in time and now it has changed.
I’m not aware of hard coding the IP address but that’s probably the reason. Thanks for your help.
To clear the DNS cache for both Safari and Chrome (it seems to have its own DNS cache) I used the steps described here: macos - How do I clear Google Chrome's DNS cache entirely? - Ask Different
Now, it’s working again. Thanks @jmangelo
1 Like