Azure Kubernetes Service deployment issue "http: TLS handshake error from <IP>:<PORT>: EOF"


I just deployed SCIM bridge following every step of the deployment guide ( everything seems to be running but when i go to the URL it gives an error 'ERR_SSL_PROTOCOL_ERROR'

In the Kubernetes logs i see a lot of TLS handshake errors and 'unable to satisfy "*****" for domain "****": no viable challenge type found'

Please assist.

Kind regards,
Robbert van Arkel

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided


  • 1P_Amanda1P_Amanda

    Team Member

    Hi @robbertvanarkel!

    There's a couple things that could be going on here. It could be port 80 is closed on your SCIM Bridge (it needs to be accessible for the LetsEncrypt challenge), or your DNS entry doesn't point to the correct External IP address of the SCIM Bridge. So check your firewall rules and ensure your DNS record is up to date and see if that fixes the issue.


  • Hi Amanda,

    I'm not to familiar with Kubernetes but what i can tell is that port 443 ad 80 are open. DSN entry is set to LoadBalancer Ingress address.

    (i blurred out the public ip address)

  • 1P_Amanda1P_Amanda

    Team Member

    Just so that we're on the same page, is the LoadBalancer Ingress address the external IP address you blurred out?

  • yes, the external IP address.
    I can post it here, not sure if that's within the community rules :)

  • 1P_Amanda1P_Amanda

    Team Member

    No, you're totally right, no need to post it. I just wanted to make sure that we were on the same page. Are there any other firewalls that might be preventing access to port 80? It looks good on the Kubernetes side.

  • When i do a port check it shows that port 80 and 443 are reachable from the internet. This is the first time i'm working with Kubernetes but as far as i can tell there is no other firewall in place.

  • Hi!

    I was able to fix it. We have a CAA entry in the dns of the domain that points to a different authority than lets encrypt and that prevents lets encrypt to provide the certificate.
    I changed the configuration of the scim bridge to a different domain and now it works.

  • ag_anaag_ana

    Team Member

    Thank you for the update @robbertvanarkel! I am glad to hear that you managed to sort things out, and thank you also for sharing the solution with the community :)

    If you have any other questions, please feel free to reach out anytime.

    Have a wonderful day :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file