Consider restricting what proxies you accept forwarded certificates from

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

We currently have a peculiar architecture, where our reverse proxy for service fabric is exposed over the public internet, and we also have an API management that hits the application directly bypassing our reverse proxy. This APIm instance will perform SSL termination and we are looking to add mutualTLS there that will validate the incoming client certificates. However, as the reverse proxy is still exposed to the internet, anyone can send their own generated certificate in the forwarded header format and we will then trust it in the application.

Currently, when you enable Certificate Forwarding, there is no validation on the proxy that has forwarded this header [available in the options. ](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.httpoverrides.certificateforwardingoptions?view=aspnetcore-9.0)

However, there is validation on the proxy that has forwarded the other headers typically done by a reverse proxy (x-proto, etc.) by setting the [KnownProxies or KnownNetworks](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.forwardedheadersoptions.knownnetworks?view=aspnetcore-9.0) value.

As a result, in some cases, [like your appservice documentation](https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth?tabs=azureportal%2Cflask), it is said that you should always validate incoming certificates that are forwarded on within the application.

However, as we are using the Azure product API Management, this allows us to do all of the [certificate validation](https://learn.microsoft.com/en-us/azure/api-management/validate-client-certificate-policy) outside of the application.

With this in mind, I want to validate that the certificate that has been forwarded comes from my expected proxy so that I can trust it without having to validate it again, but the certificate forwarding middleware does not offer that functionality - you have to validate the entire client cert.

Can we add this validation to align it with the behaviour with the forwarded headers middleware?

Thanks

### Describe the solution you'd like

Add two properties to the [CertificateForwardingOptions](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.httpoverrides.certificateforwardingoptions?view=aspnetcore-9.0) class called KnownProxies and KnownNetworks that have the same behaviour as those properties in the [ForwardedHeaderOptions](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.forwardedheadersoptions?view=aspnetcore-9.0) i.e. you only accept forwarded client certs in the header from certain IP addresses.

### Additional context

_No response_