DNS https resolution issue with docker-compose-letsencrypt.yml

I have created a new domain with its certificate who points to the server with a public IP.

When I use docker-compose-letsencrypt.yml and replaced localhost.openiap.io by test-openiap.testdomain.com I am getting this log error message in traefik:

Unable to obtain ACME certificate for domains "grpc.test-openiap.testdomain.com": unable to generate a certificate for the domains [grpc.test-openiap.testdomain.com]: error: one or more domains had a problem:\n[grpc.test-openiap.testdomain.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for grpc.test-openiap.testdomain.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for grpc.test-openiap.testdomain.com - check that a DNS record exists for this domain\n" providerName=myresolver.acme ACME CA=“https://acme-v02.api.letsencrypt.org/directory” routerName=grpc-router@docker rule="Host(grpc.test-openiap.testdomain.com)

What it means?, That I need to add the two reference DNS records to test-openiap.testdomain.com?
Is it the fix for the issue or are there any other steps involved to make this setup works?

Thanks

You are not suppose to create a certificate, that is what traefik does

you have not create the two dns records as explained on using-custom-domain-names you need to create both the dns records

I don’t understand this question … A fix for what ? if you don’t follow the instructions it will not work,

1 Like

I was making reference to a fix for the issue I am getting. I will follow your recommendation to make it works.

I already created the two records as explained at using-custom-domain-names, however the error message I am getting is about grpc.test-openiap.testdomain.com (seems like grpc is the prefix for the service), that’s my confusion.

Thanks a lot!

I am sorry if I’m misunderstanding what you are writing. I assumed from your original post that:

  • You did a search and replace on localhost.openiap.io to test-openiap.testdomain.com
  • In the interface for you public facing DNS of testdomain.com you added
    test-openiap.testdomain.com pointing to the public accessible Ip of the server with docker
    and *.test-openiap.testdomain.com as a CNAME pointing to test-openiap.testdomain.com.

In that case, anyone in the world should be able to resolve both test-openiap.testdomain.com and anything-you-want.test-openiap.testdomain.com
therefore grpc.test-openiap.testdomain.com should be covered by the CNAME and resolve to the public IP of your docker server.

If not, what part of the above is wrong (did you not do or did something different )?

Hello Allan,

Yes, that exactly what I should have, because I created a ticket giving the instructions to my IT team to look at the docs and setup the domains and the corresponding DNS records explicitly, that’s why I am assuming the records already exist, I will be verify with them and post here the results.

Thank you so much, you as always available to help.
Regards

Then i fear you may not have a public ip on the server either?

In that cade you either need to use DNS01 challenges, that will requires your public dns zone is hosted by a supported provider, or you need to run without https and use the plain (normal)docker file

1 Like

Yes exactly what I was missing, we are using a DNS provider route53 in AWS, for that reason we couldn’t make it works with docker-compose-letsencrypt.yml.

I’ll setup the deployment using DNS01 challenges to solve the problem.

Thanks you so much and have a wonderful weekend,
I will post the results here.
Regards

No, i think you misunderstand.

Http01 requires a public ip and dns pointing that ip ( does not matter where dns is hosted, but must be a public domain )
Dns01 does NOT require public ip, but requires dns is hosted at a supported provider.

If you have public ip, use http01 its much simpler.
If you dont have public ip on the server, and cannot use a supported dns provider skip using https all together.

PS: route53 is supported for dns01 but i highly recommend you use http01 if you have a public ip on the server ( and port 80 and 443 open )

That’s the setup I already tested from the beginning docker-compose-letsencrypt.yml. I got the message referenced above in Traefik because the second CNAME DNS record wasn’t created correctly. I fixed that issue however now I am getting next error message:

time="2023-08-25T17:09:18Z" level=error msg="Unable to obtain ACME certificate for domains \"test-openiap.testdomain.com\": unable to generate a certificate for the domains [test-openiap.testdomain.com]: error: one or more domains had a problem:\n[test-openiap.testdomain.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge\n" providerName=myresolver.acme ACME CA="https://acme-v02.api.letsencrypt.org/directory" routerName=http-router@docker rule="Host(`test-openiap.testdomain.com`)"

We have a load balancer with a dynamic public IP. What my team and I think if that, maybe when traefik try to create the DNS certificate, more than one call to that domain is performed and a new different IP is returned each time, causing the failure in that process.

We are going to assign an static IP to the load balancer and test it again.

Notes:
.testdomain.com already has a current DNS certificate, we just created a new subdomain test-openiap.testdomain.com for this setup.

Do you think this could be the current issue?

Thanks

Does route53 has a proxy feature like cloudflare does ?

Hi Allan,
I consulted today with my team, and yes, the load balancer in front of our server act as a reverse proxy.

Any idea?

Thanks

Disable it. You cannot use proxy as part of the ACME negotiation for ssl certificates.
Plus, that is redundant, that is what traefik does ( being reverse proxy )

They just confirmed that Route53 doesn’t work like a Cloudflare proxy that is sitting in front of your traffic protecting it. It is just redirecting the traffic to the load balancer which sends to the server.

Then, for our current openiap setup, we are not using a proxy, but using a dynamic IP, however it doesn’t change to frequently. Sorry for the misinformation.

Thanks and regards

Then I am out of idears.
If you google “ Cannot negotiate ALPN protocol” you will find 2-3 hits on page one related to aws, all talking anout proxys or firewall policies.
If docker+traefik is published unrestricted on the internet with port 80 and 443 open, it will work out of the box.

Having dynamic ips is not an issue as long as the dns name requested resolves to the same IP as the server that it is sending the request from. So just make sure to have a very low TTL in the SOA record and for the two records pointing to the docker server ( for requesting cert it just needs to match while doing the request for the certificate(s), so once every 3 months )

1 Like

We are going to review the whole schema again and follow your recommendations to make it works.

Thank you so much Allan

Hi Alan, we finally were able to deploy Openiap https using docker-compose-letsencrypt.yml, as you told it works out of the box without any issues, we had and issue in our load balancer and environment configuration and for some reason wasn’t allowing letsencrypt create the certificate.

Thank you so much for your help and this awesome framework!
Regards

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.