Access Server Web Certificate Error: Fix the Empty CA Bundle

A web login page that refuses to load while DNS resolves correctly is usually not a DNS problem. If the service log mentions an empty certificate-bundle path or a PEM parse failure for the web certificate and private key, the HTTPS listener has no usable material and no amount of name resolution will help it. The repair lives in three configuration keys, and it does not involve reissuing a single VPN client certificate.

What the three keys actually point at

The custom web certificate set is described by cs.cert, cs.priv_key and cs.ca_bundle. Each stores a path to a file, and the three are consumed together by the web service. A certificate with the wrong key, or a chain file that is actually the leaf certificate, fails the same way an empty value does: the listener cannot build a chain that a browser will accept.

These keys belong to the Admin and Client Web UI. They are separate from the PKI that issues certificates to VPN clients, so replacing them does not require touching the client profiles, the server key or the certificate authority. Treating a web TLS fault as a reason to rebuild the whole PKI is the most expensive wrong turn available here.

One distinction saves time: an explicitly empty custom value is not the same configuration state as having no override at all. The first hands the parser an empty path, which is what the log line is telling you. The second leaves Access Server on its own material, which is why some hosts start fine after an upgrade and others do not.

Why a file that exists still fails to parse

The parser reads the labelled blocks inside the file, not the file name. A .crt that contains a private key, a chain written as one concatenated blob where a single certificate was expected, or a file saved with a truncated final line will all be rejected. RFC 7468 defines those human-readable labels for a reason: they are the only thing that tells a reader what kind of object follows.

Inspect the objects rather than the extensions. On a Linux host, openssl x509 -noout -subject -issuer -in server.pem and openssl pkey -noout -check -in key.pem answer the two questions that matter, and comparing the modulus or public key of both proves they belong together. Keep private-key output out of tickets and chat logs; the check needs a fingerprint, not the key.

An empty path deserves the same suspicion as a malformed file, because both produce vague downstream errors. If the log says the bundle path is empty, read the stored value before you debug the file it was meant to point at.

Validate the set before you restart anything

Access Server's CLI includes a validation check that takes the three paths as arguments and reports whether the set is usable. The paths below are illustrative; substitute the protected locations on the host:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Read the result before touching the running service, and only then import the values and apply them through the documented operation for the installed version. The official CLI tutorial covers validation, import into the configuration database and the apply step, and its version matters more than any summary of it.

Fall back on purpose

When the custom material is broken and a valid built-in fallback is still present, the documented recovery is to remove the three custom overrides and let Access Server use that fallback. Arrange console access and a backup of the current configuration first, because the service you are about to restart is the one that serves the administration interface.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Clearing the entire configuration database is not a certificate repair. Target those three keys, apply, and confirm the web interface answers. The self-signed files under the web-ssl directory are the fallback resource, not a scratch space: overwriting or regenerating them can remove the only working material the host had.

Expect the browser to show a different certificate after the fallback takes effect. That is the correct outcome, and the answer is to verify it through your trusted administrative process, not to teach users to click through every warning they see afterwards.

Verify the name users actually type

Recovery is not finished when a TCP listener appears. Validate the DNS name, the certificate identity and the chain for that name, then load both the Admin and the Client Web UI and complete a sign-in. A port check proves none of those.

Access Server 3.1 and later can also serve different web certificates per SNI hostname. If that is configured, the default keys and the hostname-specific entries are separate sets, and testing by IP address can easily show you a different certificate than the one users get. Fix and verify the set for the name that was failing, then repeat the sign-in test before you close the incident.