[GH-ISSUE #4456] [Feature Request] Custom RootCA Support for *2https plugins

gitea-mirror commented

2026-05-05 14:15:49 -06:00

Owner

Copy link

Originally created by @adamwallred on GitHub (Sep 25, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4456

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
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @adamwallred on GitHub (Sep 25, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4456 ### 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

gitea-mirror

2026-05-05 14:15:49 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:15:53 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Sep 26, 2024):

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.

@fatedier commented on GitHub (Sep 26, 2024): 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.

gitea-mirror commented

2026-05-05 14:15:53 -06:00

Author

Owner

Copy link

@adamwallred commented on GitHub (Sep 26, 2024):

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.

@adamwallred commented on GitHub (Sep 26, 2024): > 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](https://cert-manager.io/) 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.

gitea-mirror commented

2026-05-05 14:15:54 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Oct 18, 2024):

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

@github-actions[bot] commented on GitHub (Oct 18, 2024): Issues go stale after 21d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

gitea-mirror referenced this issue

2026-05-05 14:48:26 -06:00

[PR #3520] [MERGED] update FUNDING.yml #4770

gitea-mirror referenced this issue

2026-05-05 14:48:31 -06:00

[PR #3537] [MERGED] release v0.51.1 #4774

No Branch/Tag specified