Open adamwallred opened 4 days ago
frp is commonly used for reverse proxying to your internal HTTP/HTTPS services. I believe the scenario you mentioned is not a common use case.
These plugins provide some basic functionalities, but not all of them, so we are not inclined to make changes at this point. In future major version plans, there will be a restructuring to support more complex Layer 7 proxy capabilities, and we will consider adding support at that time.
frp is commonly used for reverse proxying to your internal HTTP/HTTPS services. I believe the scenario you mentioned is not a common use case.
I would guess that internal HTTPS services have a good chance of using a custom or self-signed CA. If it's an internal service that someone has taken the time to add TLS to, then I think it's not too unexpected that the certificate is self-signed or using a custom CA. If it's an internal-only service, why would it need a commercial certificate?
For example, consider container orchestration systems like k8s that use tools like cert-manager that maintain a private CA to sign certificates for auto-generated internal service domains. Since k8s service domains are not guaranteed to be globally unique, you cannot prove ownership of them, and commercial CAs won't sign certs for them. It's common to have internal services signed by a custom CA.
Describe the feature request
The http2https and https2https plugins currently prepare the
httputil.ReverseProxy
TLS config with a hard-codedInsecureSkipVerify: true
. In cases where we have a custom CA signing the certificate for the proxied service, it would be nice to provide the CA cert and verify the connections.Describe alternatives you've considered
No response
Affected area