0

I'm having difficulty figuring out why my site is giving this error only to some users (we just migrated the domain last night) https://DavidKim2020.com

This is the error it's giving to some users:

This server could not prove that it is davidkim2020.com; its security certificate is from *.dnsmadeeasy.com. This may be caused by a misconfiguration or an attacker intercepting your connection.

We've tried changing the .htaccess, disable cache on the server, updating the cert, nothing is making it work consistently.

Any help is appreciated, thank you!

| improve this question | |
  • I’m voting to close this question because the problem disappeared. – Patrick Mevzek May 20 at 2:26
  • It doesn't happen to everyone, that's the problem – sojim2 May 20 at 2:28
  • 1
    Like everytime one does a DNS change and forgetting about TTLs and caches. See my longer explanation in my reply. In one day, the situation will clear itself out. – Patrick Mevzek May 20 at 4:56
2

On May 18th you changed your nameservers from:

ns10.nationbuilder.com
ns11.nationbuilder.com
ns12.nationbuilder.com
ns13.nationbuilder.com
ns14.nationbuilder.com
ns15.nationbuilder.com

to:

ns41.domaincontrol.com
ns42.domaincontrol.com

Old nameservers resolve your name as:

;; ANSWER SECTION:
davidkim2020.com.   2h40m IN A 96.45.82.241
davidkim2020.com.   2h40m IN A 96.45.82.83
davidkim2020.com.   2h40m IN A 96.45.83.173
davidkim2020.com.   2h40m IN A 96.45.83.119

New ones as:

;; ANSWER SECTION:
davidkim2020.com.   10m IN A 35.167.198.99

The .com TTL on NS records is 2 days. The TTL on NS records at the old nameserver is one day.

This means that some clients will still contact the old nameservers for as much as 2 days after your change, and hence get the old IP addresses for your domain. Those do not reply correctly anymore for your domains, as witnessed:

$ curl --verbose --resolve davidkim2020.com:443:96.45.82.241 https://davidkim2020.com/
* Added davidkim2020.com:443:96.45.82.241 to DNS cache
* Hostname davidkim2020.com was found in DNS cache
*   Trying 96.45.82.241...
* TCP_NODELAY set
* Connected to davidkim2020.com (96.45.82.241) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.dnsmadeeasy.com
*  start date: Mar 23 00:00:00 2020 GMT
*  expire date: Jun 25 00:00:00 2022 GMT
*  subjectAltName does not match davidkim2020.com
* SSL: no alternative certificate subject name matches target host name 'davidkim2020.com'

That is they present a certificate not compatible with the hostname, as the error message already told you. This happens when you land on some generic page at your webhosting company, like when the website is not configured properly on their side, which makes sense there as you left this provider.

Contrary to the new IP addresses:

$ curl --verbose --resolve davidkim2020.com:443:35.167.198.99 https://davidkim2020.com/
* Added davidkim2020.com:443:35.167.198.99 to DNS cache
* Hostname davidkim2020.com was found in DNS cache
*   Trying 35.167.198.99...
* TCP_NODELAY set
* Connected to davidkim2020.com (35.167.198.99) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=davidkim2020.com
*  start date: May 19 02:56:24 2020 GMT
*  expire date: Aug 17 02:56:24 2020 GMT
*  subjectAltName: host "davidkim2020.com" matched cert's "davidkim2020.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.

It is most probably that your old provider shut down all services (hence the proper HTTPS resolution) right when you switched nameservers, which is bound to cause problems like that.

Clients that contacted your website just before the change, "polluted" their cache with the old data that may be cleared only after 2 days. There is no "workaround" for things like that except waiting, and next time doing the migration differently (probably not wise to change both DNS provider and webhosting at the same time; proper DNS changes need planning).

(Technically, if you reach out to your old provider and asks him to put your server back even if they are not the authoritative nameservers anymore, then the situation should work; however I do not expect that to be possible with most providers and specially for like 2 days at most).

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.