{{sidenavigation.sidenavigationExpandLabel}}
{{getMsg('Help_YouAreHere')}}: /  {{page.title}} {{page.title}}
{{$root.getMsg("downLoadHelpAsPdf")}} {{helpModel.downloadHelpPdfDataStatus}}

Secure Access Troubleshooting

Use the symptom that best matches the problem. Check one change at a time and keep a working certificate backup before changing certificate paths.

The browser shows a certificate warning

Check that the requested hostname is included in the certificate and that the certificate is not a staging certificate or self-signed certificate. Verify that the server sends the complete certificate chain. The self-signed certificate page explains why browsers warn about test certificates.

DNS-01 validation fails

Check the TXT record at the authoritative DNS servers and at a public resolver:

dig TXT _acme-challenge.app.example.com

Verify the record name, value, TTL, CAA policy and DNS delegation. Wait for old cached values to expire. If an API module is used, check its token scope and whether it changes the authoritative zone.

Do not start a second order repeatedly while the first order is waiting for DNS propagation. This can create rate-limit errors.

DNS-PERSIST-01 reports an expired authorization

Use the exact record name and value shown by the ACME client. Check the authorization expiry and whether the client account is still the same. A staging authorization may not be accepted by a production directory. Create a new authorization when the client or certificate authority requires it.

The renewed files are not used

Check that the ACME client writes to the paths configured as the custom certificate and that the private key remains readable by the server process. If an external client performs renewal, its schedule and logs must be checked separately.

The Automatic update of custom SSL Certificates task reloads changed custom certificate files. Keep the file paths stable and verify that both the certificate and key change event is handled.

When a reverse proxy or tunnel terminates HTTPS, configure the external visible URL with the public scheme, hostname, port and context. Forward the headers listed in the Reverse Proxy Configuration page.

Tailscale Serve cannot connect

Check that the server and client are signed in to the same tailnet, that the device is approved and that ACLs allow the connection. Check the local service port and run:

tailscale serve status

Make sure the local service is listening on the address used by Serve. If it listens only on a private interface or a different port, update the Serve target or the Web Server connection settings.

A public tunnel is offline

Check the connector process, its account status and the provider's service status. Verify that the local origin port is reachable from the connector host. Review the provider access policy and confirm that the public hostname is assigned to the correct connector.

The Web Server page describes the HTTPS connection and certificate source. DNS-01 and External ACME clients provide the detailed certificate checks.

i-net CoWork
This application uses cookies to allow login. By continuing to use this application, you agree to the use of cookies.


Help