GoAhead TLS Bug Skips CRL Enforcement for Mutual-TLS Clients

Key points

• GoAhead web server deployments using an OpenSSL TLS backend are affected in certain builds.
• A CRL may be loaded, but revocation checking is not active.
• Revoked client certificates can still be accepted in mutual-TLS configurations.
• The flaw can enable session decryption and mTLS bypass.
• No CVE is assigned; review certificate-based access paths now.

Organizations running the GoAhead web server with an OpenSSL-based TLS stack are exposed to a certificate-validation weakness in certain builds. The server can load a certificate revocation list, but revocation checking is not turned on. Consequently, credentials that administrators believe are no longer trusted may continue to be honored during TLS client authentication.

The issue is most consequential in mutual-TLS deployments, where both sides present certificates. In those configurations, the server may accept a client-side certificate that should have been rejected. That creates a mutual-TLS bypass condition and can expose sessions to decryption if an attacker can complete a handshake with a revoked credential. The affected scope is limited to OpenSSL-linked builds and environments that use client-certificate authentication, but those are common in administrative and service-to-service channels.

No CVE has been assigned, so teams should not wait for a public identifier to drive response. Treat the matter as a configuration and validation defect: the presence of a CRL file does not prove that it is being applied. The risk is elevated for K-12 and government services that rely on certificate-based access control, because a bypass can undermine the assumption that only valid devices or users can connect.

Watch for vendor guidance and updated builds. Until then, test whether revoked client certificates are actually rejected, review logs for successful mutual-TLS handshakes involving credentials that should be invalid, and consider reducing reliance on client certificates at the GoAhead layer where operationally possible.

What to do now

1. Inventory every GoAhead web server instance and identify those linked to OpenSSL and configured for client-certificate authentication or mutual TLS.
2. Test a known-revoked client certificate against each endpoint; if it is accepted, treat the service as exposed.
3. Apply vendor updates for GoAhead or OpenSSL, or adjust configuration so revocation checking is actually enforced.
4. If no fix is available, terminate mutual TLS at a trusted reverse proxy or disable client-certificate authentication on affected GoAhead listeners.
5. Rotate or reissue certificates used in affected channels and review TLS logs for accepted credentials that should have been rejected.
6. Add monitoring for CRL load failures and client-certificate validation outcomes, and document the temporary compensating controls.

Original source

The Hacker News