SSL VPN Certificate Authentication Fails for Remote Users
A company has deployed a Huawei USG firewall as an SSL VPN gateway. Employees authenticate with client certificates issued by the company's internal Microsoft CA, and the firewall has a certificate signed by the same root. Local users work, but remote users began failing after a CA renewal project. The firewall clock is 12 minutes behind the domain controllers. Some clients report "certificate chain verification failed"; others connect but are placed in the wrong role and receive no internal routes. The CRL distribution point is an HTTP URL on an internal server that the firewall can reach, but the CRL has not been updated for 45 days. The new user certificates contain only the common name (CN), with no subject alternative name (SAN) or e-mail address. The VPN client profile is delivered by a public portal that uses a certificate the firewall presents.
1. What is your troubleshooting sequence for the chain verification failure, and which certificate details matter most?
Read the worked answer
Start with the firewall's trust chain. Confirm that the firewall trustpoint contains the renewed root and any intermediate CA certificates, and that the SSL VPN gateway certificate is issued by a CA whose chain terminates at that root. A renewed root with the same name but a new key is a different trust anchor; importing only the new server certificate without the new root causes chain verification failure. Check the validity dates and the firewall clock: a 12-minute skew is usually within tolerance, but if the clock is wrong by more than the allowed skew, certificate validation fails. Verify the client's clock as well.
Next inspect the certificate itself. The SAN is the field modern clients use for identity matching; a certificate with only CN may fail hostname verification against the VPN portal URL. Confirm the certificate's intended purpose includes client authentication, and that the EKU is appropriate. Check the CRL: an expired or stale CRL can cause validation failure, and the firewall must be able to reach the distribution point. Use the firewall's certificate display commands and logs to see which check failed: signature, validity, revocation, or name. Fix the trust anchor and CRL first, then reissue client certificates with SAN if hostname or identity matching requires it.
2. Why would some users connect but receive the wrong role and no routes, and how would you correct the authorization mapping?
Read the worked answer
Authentication and authorization are separate. A user can pass certificate validation and still be mapped to the wrong policy group if the firewall's role or group mapping depends on a certificate field that is missing or different. If the mapping expects an e-mail address or SAN and the new certificates contain only CN, the lookup fails and the user falls into a default role with no routes or a restricted role. Similarly, if the mapping uses the full distinguished name and the CA renewal changed the DN format or the intermediate CA, the old mapping rule no longer matches.
Correct this by choosing an attribute that is stable and present in the new certificates, such as CN, and updating the authorization rule accordingly. If CN is not unique, require SAN or e-mail in the certificate template and map on that. Test with one affected user, inspect the SSL VPN login logs for the authenticated identity and assigned role, and verify the role's route and policy assignments. Do not broaden the default role to include internal routes as a shortcut; that would give unauthenticated or mismapped users excessive access. Also confirm that the user group is referenced correctly in the SSL VPN virtual gateway configuration.
3. The CRL is 45 days old. What revocation design would you recommend, and what are the trade-offs?
Read the worked answer
A stale CRL is a validation risk: revoked certificates may still be accepted until the next CRL is published. First check why the CRL is not updating: the CA's CRL publication interval, the distribution point URL, network access from the firewall, or a proxy. Fix the publication and import path, and confirm the next update time in the CRL. If the firewall cannot reach the internal HTTP URL reliably, consider publishing the CRL to a reachable location or using a supported method such as LDAP or OCSP if the platform supports it.
The trade-off is between freshness and availability. A short CRL interval improves revocation latency but increases load and the risk that clients or the firewall reject certificates when the CRL is temporarily unavailable. OCSP gives near-real-time status but adds a dependency and privacy considerations. A practical design uses a moderately short CRL interval with a nextUpdate grace period, monitoring for CRL retrieval failures, and an alert if the CRL is older than its nextUpdate. Also ensure the firewall trusts the CRL signer and that the CRL signing key is protected. Document the fallback behavior: whether validation fails closed or open, and why.