4 ms·

Okra | REMOTE | Full-Time | Senior Engineering Manager, Principal Software Architect, Staff Full-stack Developer, Senior DevOps Engineer | https://okra.ng/ http

Okra | REMOTE | Full-Time | Senior Engineering Manager, Principal Software Architect, Staff Full-stack Developer, Senior DevOps Engineer | https://okra.ng/ https://okra.ng/ Okra is on a mission to connect 1 billion Africans to the global economy. We are here to enable innovative companies to create better and fairer financial services for everyone through the power of Open Finance. We make it super easy for people to securely connect their financial accounts to the business apps and services they choose. Our developer-friendly infrastructure supports over 100 financial institutions so the over 500 digital financial services built on Okra can be accessible to everyone. We are looking for highly motivated and experienced people to join us in solving the toughest technical challenges in financial inclusion. Connect here: https://okra.ng/careers https://okra.ng/careers and let's talk.

macintux 3y ago
I'm receiving SSL protocol errors via both Chrome and Safari under macOS.
- olddustytrail 3y ago
  I'm not. Is the time on your computer correct?
  - macintux 3y ago
    ¯\_(ツ)_/¯ Setting aside philosophical questions around relativity, yes. Thanks, will dig deeper. Curious.
    - jedberg 3y ago
      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.
      - macintux 3y ago
        Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.
    - olddustytrail 3y ago
      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.
      - macintux 3y ago
        Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.
        olddustytrail 3y ago
        How could I not think that! Reinforcement of the "it's always DNS" meme.
- serkandurusoy 3y ago
  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 https://boards.eu.greenhouse.io/okrainc
  - macintux 3y ago
    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).
    - 0xbadcafebee 3y ago
      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 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.229.64 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.

macintux 3y ago

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

olddustytrail 3y ago
I'm not. Is the time on your computer correct?
- macintux 3y ago
  ¯\_(ツ)_/¯ Setting aside philosophical questions around relativity, yes. Thanks, will dig deeper. Curious.
  - jedberg 3y ago
    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.
    - macintux 3y ago
      Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.
  - olddustytrail 3y ago
    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.
    - macintux 3y ago
      Looks like CloudFlare (1.1.1.1) is giving the wrong answers for the DNS lookup.
      - olddustytrail 3y ago
        How could I not think that! Reinforcement of the "it's always DNS" meme.
serkandurusoy 3y ago
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 https://boards.eu.greenhouse.io/okrainc
- macintux 3y ago
  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).
  - 0xbadcafebee 3y ago
    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 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.229.64 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.