[Feature Request] Custom RootCA Support for *2https plugins

[adamwallred]

Describe the feature request

The http2https and https2https plugins currently prepare the httputil.ReverseProxy TLS config with a hard-coded InsecureSkipVerify: 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

• [ ] Docs
• [ ] Installation
• [ ] Performance and Scalability
• [X] Security
• [ ] User Experience
• [ ] Test and Release
• [ ] Developer Infrastructure
• [X] Client Plugin
• [ ] Server Plugin
• [ ] Extensions
• [ ] Others

[fatedier]

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.

[adamwallred]

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.

[github-actions[bot]]

Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.