[Bug]: Change of dns name

[jojof2024]

[Bug]: Change of dns name

[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?