[GH-ISSUE #2016] frps serves invalid ssl cert even when ssl cert is provided #1602

New issue

Closed

opened 2026-05-05 13:01:18 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 13:01:18 -06:00

Owner

Originally created by @levavakian on GitHub (Sep 29, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/2016

What version of frp are you using (./frpc -v or ./frps -v)?
0.34 (latest dev)

What operating system and processor architecture are you using (go env)?
amd64/linux

Configures you used:

frpc.ini
[common]
server_addr = ***
server_port = 443
tls_enable = true
log_level = trace

[web]
type = https
local_port = 8443
custom_domains = ***

frps.ini
[common]
bind_port = 443
vhost_https_port = 443
log_level = trace
tls_cert_file = server.crt
tls_key_file = server.key
tls_only = true

Steps to reproduce the issue:

Generate ssl cert from Let's Encrypt, set certificate_pem to server.crt and private_key_pem to server.key and install them on the frps server
Run frps
visit https endpoint

Describe the results you received:
If frpc is not running, then visiting the endpoint results in an error page with ERR_SSL_PROTOCOL_ERROR and frps gives the log [vhost.go:158] http request for host [***] path [] not found

If frpc is running, the proxied webpage is served but the ssl certificate is invalid and is shown as a self signed localhost certificate.

Describe the results you expected:
If frpc is not running, I expected the regular frp 404 page with a valid ssl certificate.

If frps is running, I expected the webpage to be served and be secured by the ssl certificate on the frps server.

** Additional questions **
I am assuming that the TLS certificates installed on frps are able to sign the webpages served by the frpc client without any certificates having to be installed on the frpc client. Is that a correct assumption?

Originally created by @levavakian on GitHub (Sep 29, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/2016 **What version of frp are you using (./frpc -v or ./frps -v)?** 0.34 (latest dev) **What operating system and processor architecture are you using (`go env`)?** amd64/linux **Configures you used:** ``` frpc.ini [common] server_addr = *** server_port = 443 tls_enable = true log_level = trace [web] type = https local_port = 8443 custom_domains = *** ``` ``` frps.ini [common] bind_port = 443 vhost_https_port = 443 log_level = trace tls_cert_file = server.crt tls_key_file = server.key tls_only = true ``` **Steps to reproduce the issue:** 1. Generate ssl cert from Let's Encrypt, set certificate_pem to server.crt and private_key_pem to server.key and install them on the frps server 2. Run frps 3. visit https endpoint **Describe the results you received:** If frpc is not running, then visiting the endpoint results in an error page with `ERR_SSL_PROTOCOL_ERROR` and frps gives the log `[vhost.go:158] http request for host [***] path [] not found` If frpc is running, the proxied webpage is served but the ssl certificate is invalid and is shown as a self signed localhost certificate. **Describe the results you expected:** If frpc is not running, I expected the regular frp 404 page with a valid ssl certificate. If frps is running, I expected the webpage to be served and be secured by the ssl certificate on the frps server. ** Additional questions ** I am assuming that the TLS certificates installed on frps are able to sign the webpages served by the frpc client without any certificates having to be installed on the frpc client. Is that a correct assumption?

gitea-mirror closed this issue

2026-05-05 13:01:19 -06:00

gitea-mirror commented

2026-05-05 13:01:21 -06:00

Author

Owner

@fatedier commented on GitHub (Sep 30, 2020):

The tls_cert_file in frps is only for TLS connections from frpc, not for vhost-https proxy. We just forward vhost-https connections to frpc by SNI, not decode content.

@fatedier commented on GitHub (Sep 30, 2020): The `tls_cert_file` in frps is only for TLS connections from frpc, not for vhost-https proxy. We just forward vhost-https connections to frpc by SNI, not decode content.

gitea-mirror commented

2026-05-05 13:01:22 -06:00

Author

Owner

@levavakian commented on GitHub (Sep 30, 2020):

Ah ok, so it is impossible to have frps handle the tls termination on behalf of frpc, while still keeping the communication between frps and frpc tls secured?

@levavakian commented on GitHub (Sep 30, 2020): Ah ok, so it is impossible to have frps handle the tls termination on behalf of frpc, while still keeping the communication between frps and frpc tls secured?

gitea-mirror commented

2026-05-05 13:01:23 -06:00

Author

Owner

@fatedier commented on GitHub (Sep 30, 2020):

Yes.

@fatedier commented on GitHub (Sep 30, 2020): Yes.

gitea-mirror commented

2026-05-05 13:01:24 -06:00

Author

Owner

@mredbishop commented on GitHub (Feb 7, 2025):

My god Chat GPT led me down the garden path before I found this comment 🤦

Reasoned about TLS termination with FRP for 21 seconds

Hi Ed, FRP absolutely supports TLS termination when set up correctly. Your
config looks about right, so the error suggests that instead of handling the TLS
handshake, FRPS might be simply forwarding plain HTTP from your local service.
Could you try this command to see if it returns an HTTP response?

@mredbishop commented on GitHub (Feb 7, 2025): My god Chat GPT led me down the garden path before I found this comment 🤦 ``` Reasoned about TLS termination with FRP for 21 seconds Hi Ed, FRP absolutely supports TLS termination when set up correctly. Your config looks about right, so the error suggests that instead of handling the TLS handshake, FRPS might be simply forwarding plain HTTP from your local service. Could you try this command to see if it returns an HTTP response? ```