search

smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.36k stars 415 forks source link

[Bug]: Change of dns name #1814

Open jojof2024 opened 2 months ago

jojof2024 commented 2 months ago

Steps to Reproduce

init the step ca with the following dns name xxxlhgroup.de. I changed the dns name in ca.json and default.json to latest.lhgroup.de. And now I send a certificate request over certbot.

Your Environment

Expected Behavior

The ca uses the dns name latest.lhgroup.de for the certificate request.

Actual Behavior

I make a certificate request over certbot (certbot certonly --standalone -d example --server https://latest.lhgroup.de/acme/acme1day/directory) and it changes the dns name from latest.lhgroup.de to xxxlhgroup.de in the ca response.

INFO[0021] duration="131.201µs" duration-ns=131201 fields.time="2024-04-29T16:21:36+02:00" method=GET name=ca path=/acme/acme1day/directory protocol=HTTP/1.1 referer= remote-address=xxxx request-id=conqps7a49jreql0aaeg response="{\"newNonce\":\" https://xxxlhgroup.de/acme/acme1day/new-nonce\",\"newAccount\":\"https://xxxx.lhgroup.de/acme/acme1day/new-account\",\"newOrder\":\"https://xxxx.lhgroup.de/acme/acme1day/new-order\",\"revokeCert\":\"https://xxxlhgroup.de/acme/acme1day/revoke-cert\",\"keyChange\":\"https://xxxlhgroup.de/acme/acme1day/key-change\"}" size=382 status=200 user-agent="CertbotACMEClient/1.22.0 (certbot; Red Hat Enterprise Linux 8.9 (Ootpa)) Authenticator/standalone Installer/None (certonly; flags: ) Py/3.6.8" user-id=

Additional Context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

hslatman commented 2 months ago

Hey @jojof2024, did you send the SIGHUP signal to the CA or restart the CA after changing the configuration? I.e. something like killall -i -s SIGHUP step-ca

jojof2024 commented 2 months ago

Hey, yes we did restart the CA. And the old DNS name is no where to be found in the ca.json or the default.json. Do we have to remove the old DNS name somewhere else to. How can this happen?

jojof2024 commented 2 months ago

It also says that it runs with the latest dns name. The primary server URL is latest.lhgroup.de. But it does not matter, when I send a certbot request with latest.lhgroup.de url it changes in at the moment of the connection to the old dns name xxxlhgroup.de.

certbot certonly --standalone -d example --server https://latest.lhgroup.de/acme/acme1day/directory -m email -vvv Root logging level set at 0 Saving debug log to /var/log/letsencrypt/letsencrypt.log Requested authenticator standalone and installer None Single candidate plugin: standalone Description: Spin up a temporary webserver Interfaces: Authenticator, Plugin Entry point: standalone = certbot._internal.plugins.standalone:Authenticator Initialized: <certbot._internal.plugins.standalone.Authenticator object at 0x7f529f3e2f28> Prep: True Selected authenticator <certbot._internal.plugins.standalone.Authenticator object at 0x7f529f3e2f28> and installer None Plugins selected: Authenticator standalone, Installer None Sending GET request to https://latest.lhgroup.de/acme/acme1day/directory. Starting new HTTPS connection (1): latest.lhgroup.de:443 https://latest.lhgroup.de:443 "GET /acme/acme1day/directory HTTP/1.1" 200 382 Received response: HTTP 200 Cache-Control: private, max-age=86400, no-cache, must-revalidate Pragma: no-cache Content-Type: application/json Expires: -1 X-Powered-By: ARR/3.0 Strict-Transport-Security: max-age=31536000;includeSubdomains X-Frame-Options: sameorigin Content-Security-Policy: default-src 'self' .latest.lhgroup.de data:; style-src .latest.lhgroup.de 'unsafe-inline'; script-src .pki-np.app.lhgroup.de 'unsafe-inline' 'unsafe-eval' X-Content-Type-Options: nosniff; case-insensitive Date: Tue, 30 Apr 2024 06:17:09 GMT Content-Length: 382

{"newNonce":"https://xxxx.lhgroup.de/acme/acme1day/new-nonce","newAccount":"https://xxxx.lhgroup.de/acme/acme1day/new-account","newOrder":"https://xxxx.lhgroup.de/acme/acme1day/new-order","revokeCert":"https://xxxx.lhgroup.de/acme/acme1day/revoke-cert","keyChange":"https://xxxx.lhgroup.de/acme/acme1day/key-change"}

Please read the Terms of Service at None. You must agree in order to register with the ACME server. Do you agree?

(Y)es/(N)o: y Requesting fresh nonce Sending HEAD request to https://xxxx.lhgroup.de/acme/acme1day/new-nonce. Starting new HTTPS connection (1): xxxx.lhgroup.de:443

hslatman commented 2 months ago

Have you tried executing step ca health, and does that return an OK? What do you see when you visit https://latest.lhgroup.de/acme/acme1day/directory in a browser?

It looks like there's a proxy in between: X-Powered-By: ARR/3.0. Is it possible that's what's interfering with the request?

jojof2024 commented 2 months ago

step ca Health is ok. It schould not be our proxy. In the ca logs we find: The primary server URL is latest.lhgroup.de

and

response="{"newNonce":" https://xxxlhgroup.de/acme/acme1day/new-nonce","newAccount":"https://xxxx.lhgroup.de/acme/acme1day/new-account","newOrder":"https://xxxx.lhgroup.de/acme/acme1day/new-order","revokeCert":"https://xxxlhgroup.de/acme/acme1day/revoke-cert","keyChange":"https://xxxlhgroup.de/acme/acme1day/key-change"}"

hslatman commented 2 months ago

step ca Health is ok. It schould not be our proxy. In the ca logs we find: The primary server URL is latest.lhgroup.de

and

response="{"newNonce":" https://xxxlhgroup.de/acme/acme1day/new-nonce","newAccount":"https://xxxx.lhgroup.de/acme/acme1day/new-account","newOrder":"https://xxxx.lhgroup.de/acme/acme1day/new-order","revokeCert":"https://xxxlhgroup.de/acme/acme1day/revoke-cert","keyChange":"https://xxxlhgroup.de/acme/acme1day/key-change"}"

The CA will reply with xxxlhgroup.de in the ACME directory if the ACME client requests it by that domain, as it will extract the host to use from the request. It'll use the latest.lhgroup.de only as a fallback. Is it possible the ACME client kept using the old URL in some way?

jojof2024 commented 2 months ago

We tried it also with different clients (certbot (redhat client) and win-acme) all with the same responce. The win-acme client was just recently set up and did not send any request before this test.

hslatman commented 2 months ago

What's shown when you go to https://latest.lhgroup.de/acme/acme1day/directory in a browser?

jojof2024 commented 2 months ago

I get the exact same responce: "newNonce":"[https://xxxx.lhgroup.de/acme/acme1day/new-nonce", "newAccount":"https://xxxx.lhgroup.de/acme/acme1day/new-account", "newOrder":"https://xxxx.lhgroup.de/acme/acme1day/new-order", "revokeCert":"https://xxxx.lhgroup.de/acme/acme1day/revoke-cert"

hslatman commented 2 months ago

What response headers does the browser console show?

jojof2024 commented 2 months ago

Cache-Control: private, max-age=86400, no-cache, must-revalidate Content-Length: 382 Content-Security-Policy: default-src 'self' .latest.lhgroup.de data:; style-src .latest.lhgroup.de 'unsafe-inline'; script-src *.latest.lhgroup.de 'unsafe-inline' 'unsafe-eval' Content-Type: application/json Date: Tue, 30 Apr 2024 14:29:49 GMT Expires: -1 Pragma: no-cache Strict-Transport-Security: max-age=31536000;includeSubdomains X-Content-Type-Options: nosniff; case-insensitive X-Frame-Options: sameorigin X-Powered-By: ARR/3.0

hslatman commented 2 months ago

I still suspect the proxy may have something to do with it. Can you try it without going through the proxy in your browser?

dopey commented 2 months ago

I just tested this locally and I get the correct urls being served from the /directory ACME endpoints after update. I started with FQDN ca.smallstep.com and I changed to ca1.smallstep.com. When I curl the directory structure after making the change in the ca.json and SIGHUP-ing the step-ca service, I get: 

{"newNonce":"https://ca1.smallstep.com:8081/acme/acme2/new-nonce","newAccount":"https://ca1.smallstep.com:8081/acme/acme2/new-account","newOrder":"https://ca1.smallstep.com:8081/acme/acme2/new-order","revokeCert":"https://ca1.smallstep.com:8081/acme/acme2/revoke-cert","keyChange":"https://ca1.smallstep.com:8081/acme/acme2/key-change"}

I agree with @hslatman that there may be an issue with cacheing in your proxy layer?

jojof2024 commented 1 month ago

We run our tests now without the proxy in the middle but unfortunately the ca did respond with the wrong url. Is there a way we can assure that the ca responds with the primary url? Because it says that it runs primarly with our latest url but in the responce message is the wrong url.

hslatman commented 1 month ago

@jojof2024 the CA will always return the URL in the directory with the one it is requested with, as long as it can determine the right value from the HTTP request, in which case it will fallback to the one that's configured on the CA side. If you're still seeing the old URL, there must be something else interfering with the request.