SSL/TLS handshake error despite Certificate Issued

[TheBestJoke]

Howdy lads.

I’ve been getting SSL/TLS Certificate errors on my Render hosted Web Service app despite the fact that in the Dashboard UI the Certificate has been issued.

curl -vI https://btci.app

* Host btci.app:443 was resolved.
* IPv6: (none)
* IPv4: 216.24.57.1, 15.197.225.128, 3.33.251.168
*   Trying 216.24.57.1:443...
* Connected to btci.app (216.24.57.1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* LibreSSL/3.3.6: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure
* Closing connection
curl: (35) LibreSSL/3.3.6: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure

Granted, I’m not 100% sure this errors belongs to the Render community, but because I changed nothing NGINX or DNS wise from one day to the next and this problem started popping up on its own, I figured I might as well ask.

[TheBestJoke]

openssl s_client -connect btci.app:443 -tls1_2                                                                                                                                     

Connecting to 216.24.57.1
CONNECTED(00000006)
C09D9A5AF87F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:907:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 211 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1729618352
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

[Jason-Render]

The problem here is those non-Render IP addresses in your DNS records. You should either use one, or the other, but not both. I’m unfamiliar with the specifics of managing AWS Global Accelerator, but if it acts as a proxy you should have only its DNS records in place, and configured to terminate connections to Render as necessary.

Unfortunately, the “Certificate Issued” is likely a false positive in this case, because non-Render IP addresses prevent Certificate Issuance from taking place, as all IPs returned must be tested, and succeed, in order for a certificate to be provided to a domain.

[TheBestJoke]

Hi Jason!

Many thanks on the tip. I solved my issue.

Turns out the problem was on GoDaddy’s end; they had generated those A Type DNS records when originally purchasing the domain because of their (very annoying) attempts to lock you into their Website Maker ecosystem – made extra aggravating because you can’t simply delete those DNS records from the DNS dashboard because they’ve been “created by another product”.

In the rare case anybody else is having the same problem, here’s what you gotta do:

• Follow the steps of this video: https://www.youtube.com/watch?v=ZG9tuiC9JDs
• After deleting the Website Maker Service, make sure you also don’t have other GoDaddy services that create DNS records on their own like DNS forwarding and the like.

And that’s pretty much it, once you have “as clean as possible” a DNS dashboard, then you can simply follow the steps of adding Custom domains as seen here. And then it’s just a matter of waiting for the propagation to do its thing.

Again, thanks for the tip Jason. I wouldn’t have managed to figure it out if it wasn’t for it.