zlacker

I'm receiving SSL protocol errors via both Chrome and Safari under macOS.

>>macint+(OP)
I'm not. Is the time on your computer correct?

>>olddus+Y4
¯\_(ツ)_/¯ Setting aside philosophical questions around relativity, yes.

Thanks, will dig deeper. Curious.

>>macint+e8
Works for me too. Have you modified your trust store and removed signers? It's signed by the Amazon Root CA, so it's a short chain, but if you removed them then it would show as invalid.

>>macint+(OP)
I'm sorry to hear you had trouble.

While I make sure we check things on our end, here is the direct link for the greenhouse application page

https://boards.eu.greenhouse.io/okrainc

>>macint+e8
That's the usual cause of protocol errors. The other one is unable to get a common cipher but that seems unlikely on a modern machine. Maybe try the connection with openssl and see if you can get some details.

>>jedber+qa
Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.

>>olddus+Yc
Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.

>>serkan+6b
After hopping onto VPN and getting it to work I discovered that pointing my DNS to CloudFlare appears to be an issue.

Reasonable answers:

    ;; ANSWER SECTION:
    okra.ng.  60 IN A 13.225.63.61
    okra.ng.  60 IN A 13.225.63.113
    okra.ng.  60 IN A 13.225.63.21
    okra.ng.  60 IN A 13.225.63.37
    
    ;; AUTHORITY SECTION:
    okra.ng.  211 IN NS ns-1302.awsdns-34.org.
    okra.ng.  211 IN NS ns-1628.awsdns-11.co.uk.
    okra.ng.  211 IN NS ns-644.awsdns-16.net.
    okra.ng.  211 IN NS ns67.domaincontrol.com.
    
    

Answers via 1.1.1.1:

    ;; ANSWER SECTION:
    okra.ng.  60 IN A 52.85.247.56
    okra.ng.  60 IN A 52.85.247.35
    okra.ng.  60 IN A 52.85.247.69
    okra.ng.  60 IN A 52.85.247.124

Not sure what to make of the lack of an authority section.

`dig @1.1.1.1 okra.ng` should allow you to reproduce (or perhaps my computer is simply hallucinating).

>>macint+Wg
How could I not think that! Reinforcement of the "it's always DNS" meme.

>>macint+Ch
It's normal for geo-located services to provide different IP addresses depending on the resolver. You can resolve DNS from around the world with different resolvers/providers here: https://dnschecker.org/#A/okra.ng

Do a Whois on the IP address (ex. https://whois.arin.net/rest/net/NET-99-86-0-0-1/pft?s=99.86....) and you will find who it's registered to. All of the different IPs belong to AMAZO-CF. This is almost certainly Amazon CloudFront, providing different endpoints (with different IPs) around the world depending on where the resolver is.

You're getting different IPs depending on whether you use one network or another, or one DNS resolver or another, because that's how CloudFront works (in this configuration).

WRT the certificate errors: It's of course possible that one endpoint out of many could have had a problem serving a certificate, but CloudFront is a pretty reliable service; it's likely if there was a problem with one endpoint it would have been happening with all of them. The most likely reason for certificate errors for one person in this case is the problem was on the user's end.

>>0xbadc+MR
Entirely possible it’s something on my end, but if so it’s impacting all of my iOS and macOS devices (haven’t spun up a Windows VM, suppose I could do that), both via web browsers and openssl itself.