Azure Kubernetes Service deployment issue "http: TLS handshake error from <IP>:<PORT>: EOF"
Hi!
I just deployed SCIM bridge following every step of the deployment guide (https://support.1password.com/scim-deploy-azure/) 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 "https://acme-v02.api.letsencrypt.org/acme/authz-v3/*****" 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
Comments
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.
Cheers!
Amanda
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)
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
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.
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 :)