-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Open
Labels
area-middlewareIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlewaresIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlewares
Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
The certificate forwarding middleware only parses base64-encoded PEM certificates. When the certificate is URL-encoded (as is standard with some reverse proxies), it fails to parse the certificate and populate HttpContext.Connection.ClientCertificate. This limits compatibility with common reverse proxies that perform mutual TLS and URL-encode the client certificate in headers.
I think it is this function that would need to be updated to return the certificate from both a url encoded or base64 encoded PEM certificate in the specified header.
public Func<string, X509Certificate2> HeaderConverter = (headerValue) => new X509Certificate2(Convert.FromBase64String(headerValue)); |
Expected Behavior
The middleware should correctly parse and return the client certificate from the header for both base64-encoded and URL-encoded PEM certificates in the specified header.
Steps To Reproduce
- Configure a reverse proxy (e.g., Azure Application Gateway or AWS ALB) to perform mutual TLS and forward the client certificate in a header.
- Deploy an ASP.NET Core application using the Certificate Forwarding Middleware.
- Observe the behavior when the forwarded certificate is URL-encoded.
Exceptions (if any)
No response
.NET Version
8.0.410
Anything else?
No response
Metadata
Metadata
Assignees
Labels
area-middlewareIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlewaresIncludes: URL rewrite, redirect, response cache/compression, session, and other general middlewares