github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #4592] Certificate Revocation List (CRL) Not Being Enforced in TLS Verification #3630

New issue

Closed

opened 2026-05-05 14:19:50 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 14:19:50 -06:00

Owner

Originally created by @dineshimatrix on GitHub (Dec 17, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4592

Bug Description

Description

The FRP server is not enforcing Certificate Revocation List (CRL) checks during TLS handshake, allowing revoked client certificates to establish connections successfully.

Environment

FRP Version: 0.54.0
OS: Ubuntu (Server), Debian (Client)
Architecture: amd64 (Server), arm64 (Client)

Current Behavior

When a client certificate is revoked and listed in the CRL, the FRP server still accepts connections from clients using that revoked certificate. This happens despite:

The certificate being properly revoked
The CRL being correctly generated and configured
OpenSSL verify command confirming the certificate is revoked

Expected Behavior

The FRP server should reject connections from clients presenting revoked certificates during the TLS handshake.

frpc Version

0.54.0

frps Version

0.54.0

System Architecture

ubuntu/amd64 on server and debian/arm64 on client

Configurations

Server side frps.toml

bindAddr = "0.0.0.0"
bindPort = 7000

auth.token = "***********************************"

webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "admin"

security.tls.certFile = "/etc/frp/ssl/cert.pem"
security.tls.keyFile = "/etc/frp/ssl/server.key"
security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem"
security.tls.clientCrlFile = "/etc/frp/ssl/ca.crl.der"
security.tls.serverName = "frp.server"
security.tlsOnly = true
security.tls.requireAndVerifyClientCert = true
security.tls.verifyDepth = 1

allowPorts = [
{ start = 2201, end = 2300 },
{ start = 8001, end = 8100 }
]

log.to = "console"
log.level = "debug"

Client side frpc.toml

serverAddr = "MY_SERVER_PUBLIC_IP"
bindPort = 7000

auth.token = "*****************************************"

security.tls.certFile = "/etc/frp/ssl/test-client.crt"
security.tls.keyFile = "/etc/frp/ssl/test-client.key"
security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem"
security.tls.serverName = "frp.server"
security.tlsOnly = true

proxies
name = "test-client"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 2201

log.to = "console"
log.level = "info"

Logs

OpenSSL verification shows certificate is revoked

$ openssl verify -CAfile ca.pem -crl_check_all -CRLfile ca.crl test-client.crt
CN = test-client
error 23 at 0 depth lookup: certificate revoked
error test-client.crt: verification failed

Server Logs show successful connection despite revocation

2024/12/17 02:59:22 [I] [root.go:105] frps uses config file: /etc/frp/frps.toml
2024/12/17 02:59:22 [I] [service.go:225] frps tcp listen on 0.0.0.0:7000
2024/12/17 02:59:22 [I] [root.go:114] frps started successfully
2024/12/17 03:15:07 [I] [service.go:563] [client_id] client login info: ip [x.x.x.x:port] version [0.54.0] hostname [] os [linux] arch [arm64]

Certificate details

Certificate Serial: 02:e1:81:f4:11:6f:a2:27:88:28:9e:98:b8:f7:be:8b:bc:60:88:4b
Listed in CRL with same serial number (confirmed revoked)

Additional Information

CRL is properly formatted and readable (verified using openssl crl -in ca.crl -text -noout)
Tried both PEM and DER formats for CRL
Tested with additional TLS verification parameters (requireAndVerifyClientCert = true)
OpenSSL command line tools correctly identify the certificate as revoked
The issue persists across server restarts

Steps to reproduce

Steps to Reproduce

Set up FRP server with TLS configuration:

security.tls.certFile = "/etc/frp/ssl/cert.pem"
security.tls.keyFile = "/etc/frp/ssl/server.key"
security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem"
security.tls.clientCrlFile = "/etc/frp/ssl/ca.crl"
security.tls.serverName = "frp.server"
security.tlsOnly = true


### Affected area

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

Originally created by @dineshimatrix on GitHub (Dec 17, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4592 ### Bug Description ### Description The FRP server is not enforcing Certificate Revocation List (CRL) checks during TLS handshake, allowing revoked client certificates to establish connections successfully. ### Environment - FRP Version: 0.54.0 - OS: Ubuntu (Server), Debian (Client) - Architecture: amd64 (Server), arm64 (Client) ### Current Behavior When a client certificate is revoked and listed in the CRL, the FRP server still accepts connections from clients using that revoked certificate. This happens despite: 1. The certificate being properly revoked 2. The CRL being correctly generated and configured 3. OpenSSL verify command confirming the certificate is revoked ### Expected Behavior The FRP server should reject connections from clients presenting revoked certificates during the TLS handshake. ### frpc Version 0.54.0 ### frps Version 0.54.0 ### System Architecture ubuntu/amd64 on server and debian/arm64 on client ### Configurations ## Server side frps.toml bindAddr = "0.0.0.0" bindPort = 7000 auth.token = "***********************************" webServer.addr = "0.0.0.0" webServer.port = 7500 webServer.user = "admin" webServer.password = "admin" security.tls.certFile = "/etc/frp/ssl/cert.pem" security.tls.keyFile = "/etc/frp/ssl/server.key" security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem" security.tls.clientCrlFile = "/etc/frp/ssl/ca.crl.der" security.tls.serverName = "frp.server" security.tlsOnly = true security.tls.requireAndVerifyClientCert = true security.tls.verifyDepth = 1 allowPorts = [ { start = 2201, end = 2300 }, { start = 8001, end = 8100 } ] log.to = "console" log.level = "debug" ## Client side frpc.toml serverAddr = "MY_SERVER_PUBLIC_IP" bindPort = 7000 auth.token = "*****************************************" security.tls.certFile = "/etc/frp/ssl/test-client.crt" security.tls.keyFile = "/etc/frp/ssl/test-client.key" security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem" security.tls.serverName = "frp.server" security.tlsOnly = true [[proxies]] name = "test-client" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 2201 log.to = "console" log.level = "info" ### Logs ## OpenSSL verification shows certificate is revoked $ openssl verify -CAfile ca.pem -crl_check_all -CRLfile ca.crl test-client.crt CN = test-client error 23 at 0 depth lookup: certificate revoked error test-client.crt: verification failed ## Server Logs show successful connection despite revocation 2024/12/17 02:59:22 [I] [root.go:105] frps uses config file: /etc/frp/frps.toml 2024/12/17 02:59:22 [I] [service.go:225] frps tcp listen on 0.0.0.0:7000 2024/12/17 02:59:22 [I] [root.go:114] frps started successfully 2024/12/17 03:15:07 [I] [service.go:563] [client_id] client login info: ip [x.x.x.x:port] version [0.54.0] hostname [] os [linux] arch [arm64] ## Certificate details Certificate Serial: 02:e1:81:f4:11:6f:a2:27:88:28:9e:98:b8:f7:be:8b:bc:60:88:4b Listed in CRL with same serial number (confirmed revoked) ### Additional Information 1. CRL is properly formatted and readable (verified using openssl crl -in ca.crl -text -noout) 2. Tried both PEM and DER formats for CRL 3. Tested with additional TLS verification parameters (requireAndVerifyClientCert = true) 4. OpenSSL command line tools correctly identify the certificate as revoked 5. The issue persists across server restarts ### Steps to reproduce ### Steps to Reproduce 1. Set up FRP server with TLS configuration: ```toml security.tls.certFile = "/etc/frp/ssl/cert.pem" security.tls.keyFile = "/etc/frp/ssl/server.key" security.tls.trustedCaFile = "/etc/frp/ssl/ca.pem" security.tls.clientCrlFile = "/etc/frp/ssl/ca.crl" security.tls.serverName = "frp.server" security.tlsOnly = true ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [X] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 14:19:51 -06:00

gitea-mirror commented

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

Author

Owner

@fatedier commented on GitHub (Dec 17, 2024):

What is the typical behavior in other common proxies?

@fatedier commented on GitHub (Dec 17, 2024): What is the typical behavior in other common proxies?

gitea-mirror commented

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

Author

Owner

@dineshimatrix commented on GitHub (Dec 17, 2024):

Hi @fatedier , Thanks for your reply. I didn't tested it in other proxies. but i checked in Chatgpt and found as,

Immediate rejection of revoked certificates during TLS handshake
No establishment of connection when certificate is in CRL
Behavior matches OpenSSL's verification (as shown in our

@dineshimatrix commented on GitHub (Dec 17, 2024): Hi @fatedier , Thanks for your reply. I didn't tested it in other proxies. but i checked in Chatgpt and found as, 1. Immediate rejection of revoked certificates during TLS handshake 2. No establishment of connection when certificate is in CRL 3. Behavior matches OpenSSL's verification (as shown in our

gitea-mirror commented

2026-05-05 14:19:55 -06:00

Author

Owner

@dineshimatrix commented on GitHub (Dec 19, 2024):

Hi @fatedier ,
Please any update here.
Thanks

@dineshimatrix commented on GitHub (Dec 19, 2024): Hi @fatedier , Please any update here. Thanks

gitea-mirror commented

2026-05-05 14:19:56 -06:00

Author

Owner

@fatedier commented on GitHub (Dec 20, 2024):

We use the default behavior of the Go standard library and currently do not plan to support this feature, unless there is a widely used proxy service we can refer to.

@fatedier commented on GitHub (Dec 20, 2024): We use the default behavior of the Go standard library and currently do not plan to support this feature, unless there is a widely used proxy service we can refer to.