[Bug]: Change of dns name

[jojof2024]

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

• OS - Redhat 8.9
• step-ca Version - 0.25.2

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]

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]

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]

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]

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]

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]

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]

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]

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

[jojof2024]

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]

What response headers does the browser console show?

[jojof2024]

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]

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]

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]

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]

@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.