-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ovh: follow cname #1467
ovh: follow cname #1467
Conversation
Hello, I think that your PR just breaks the current working implementation without CNAME. You have to find another approach. |
Hi, what would you make think so ? |
You should prove that your PR works with and without CNAME. You should be able to do: (and put the output of this command to a comment in your PR) rm -rf .lego
./lego -m your@email.com --dns ovh -d *.example.com -d example.com -s https://acme-staging-v02.api.letsencrypt.org/directory run Note the wildcard domain is important. In the 2 situations. |
I have made the following tests :
The current code always follow CNAME during pre checking, but follow CNAME for setting TXT record only if |
I am not putting all the logs but here logs with no CNAME. email,domain and key changed
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 👍
The LEGO_EXPERIMENTAL_CNAME_SUPPORT replaces the fqdn with a CNAME if it exists.
Actually OVH DNS provider create the TXT record on the original domain zone and does not follow the CNAME as intended.
Note:
Lets encrypt states that it follows cname so it would check if _acme-challenge.domain1 contains a CNAME and check the TXT record on that pointer.
so not only domain1 should point to domain2 but _acme-challenge.domain1 should point to anysubdomain.domain2
in case of using wildcards it should be better to add a cname record to point _acme-challenge.domain1 to _acme-challenge.domain2
Should be tested and reviewed
Fixes #1272