[GH-ISSUE #3515] How to set up Lets Encrypt for server verification?

gitea-mirror commented

2026-05-05 13:48:50 -06:00

Owner

Originally created by @hwittenborn on GitHub (Jul 4, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3515

Bug Description

I have a token set up on my frps instance, but I need my clients to be able to send their copy of the token to the server over the public internet, and likewise am wanting to set up a TLS certificate.

I saw in the README that Let's Encrypt can be used for certificate verification, but I'm unsure on where to obtain all of the needed certificates.

Just putting this here as a reference, but looking in Let's Encrypt configuration directory there's four files:

privkey.pem
fullchain.pem
chain.pem
cert.pem

And the accompanied README says this:

This directory contains your keys and certificates.

`privkey.pem`  : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem`     : will break many server configurations, and should not be used
                 without reading further documentation (see link below).

WARNING: DO NOT MOVE OR RENAME THESE FILES!
         Certbot expects these files to remain in this location in order
         to function properly!

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

I'm unsure on what to place where, would you know?

I also saw in the README that it says a root cert is needed, but those are owned by certificate authorities right (i.e. that's secret to Let's Encrypt)?

Sorry if there's just something I'm missing, feel free to correct me if I'm overlooking something.

frpc Version

N/A

frps Version

N/A

System Architecture

N/A

Configurations

N/A

Logs

No response

Steps to reproduce

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 @hwittenborn on GitHub (Jul 4, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3515 ### Bug Description I have a token set up on my `frps` instance, but I need my clients to be able to send their copy of the token to the server over the public internet, and likewise am wanting to set up a TLS certificate. I [saw in the `README`](https://github.com/fatedier/frp#tls) that Let's Encrypt can be used for certificate verification, but I'm unsure on where to obtain all of the needed certificates. Just putting this here as a reference, but looking in Let's Encrypt configuration directory there's four files: - `privkey.pem` - `fullchain.pem` - `chain.pem` - `cert.pem` And the accompanied README says this: ```md This directory contains your keys and certificates. `privkey.pem` : the private key for your certificate. `fullchain.pem`: the certificate file used in most server software. `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. `cert.pem` : will break many server configurations, and should not be used without reading further documentation (see link below). WARNING: DO NOT MOVE OR RENAME THESE FILES! Certbot expects these files to remain in this location in order to function properly! We recommend not moving these files. For more information, see the Certbot User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates. ``` I'm unsure on what to place where, would you know? I also saw in the README that it says a root cert is needed, but those are owned by certificate authorities right (i.e. that's secret to Let's Encrypt)? Sorry if there's just something I'm missing, feel free to correct me if I'm overlooking something. ### frpc Version N/A ### frps Version N/A ### System Architecture N/A ### Configurations N/A ### Logs _No response_ ### Steps to reproduce _No response_ ### Affected area - [ ] Docs - [X] 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 13:48:50 -06:00

gitea-mirror commented

2026-05-05 13:48:53 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 20, 2023):

I'm not entirely sure, but perhaps this content could be helpful to you?
https://stackoverflow.com/questions/50389883/generate-crt-key-ssl-files-from-lets-encrypt-from-scratch

@fatedier commented on GitHub (Jul 20, 2023): I'm not entirely sure, but perhaps this content could be helpful to you? https://stackoverflow.com/questions/50389883/generate-crt-key-ssl-files-from-lets-encrypt-from-scratch

gitea-mirror commented

2026-05-05 13:48:54 -06:00

Author

Owner

@hwittenborn commented on GitHub (Jul 20, 2023):

I'm sorry to say it, but I've moved over to https://github.com/rapiz1/rathole for the time being @fatedier.

Something I think could be really helpful for this program though is implementing https://github.com/rapiz1/rathole/blob/main/docs/transport.md#noise-protocol, which makes the setup process much easier compared to setting up TLS certificates. It was actually the main reason I moved over to it, as automating the setup process for TLS certificates proved to be a bit tedious, especially compared to being able to run a single command and then only having to share two strings between the server and clients like rathole does.

I'll go ahead and get this closed since it's effectively solved for me, but thanks for the work on this program regardless! I do hope you'll at least look into the Noise protocol stuff rathole is using, as I do think it improves the user experience when encryption is needed quite a bit.

@hwittenborn commented on GitHub (Jul 20, 2023): I'm sorry to say it, but I've moved over to https://github.com/rapiz1/rathole for the time being @fatedier. Something I think could be really helpful for this program though is implementing https://github.com/rapiz1/rathole/blob/main/docs/transport.md#noise-protocol, which makes the setup process much easier compared to setting up TLS certificates. It was actually the main reason I moved over to it, as automating the setup process for TLS certificates proved to be a bit tedious, especially compared to being able to run a single command and then only having to share two strings between the server and clients like rathole does. I'll go ahead and get this closed since it's effectively solved for me, but thanks for the work on this program regardless! I do hope you'll at least look into the Noise protocol stuff rathole is using, as I do think it improves the user experience when encryption is needed quite a bit.

gitea-mirror commented

2026-05-05 13:48:55 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 20, 2023):

Thank you for your suggestion, but I feel that there are already plenty of tools and documentation surrounding TLS, which should be sufficient to solve the majority of people's problems. I have no intention of introducing less widely-used protocols, as this would make it very difficult to integrate with other tools/proxies.

By the way, if you need to encrypt and avoid transmitting tokens in plain text, in the new version, you actually don't need to do any configuration. This is the default behavior.

@fatedier commented on GitHub (Jul 20, 2023): Thank you for your suggestion, but I feel that there are already plenty of tools and documentation surrounding TLS, which should be sufficient to solve the majority of people's problems. I have no intention of introducing less widely-used protocols, as this would make it very difficult to integrate with other tools/proxies. By the way, if you need to encrypt and avoid transmitting tokens in plain text, in the new version, you actually don't need to do any configuration. This is the default behavior.

gitea-mirror commented

2026-05-05 13:48:55 -06:00

Author

Owner

@hwittenborn commented on GitHub (Jul 20, 2023):

I feel that there are already plenty of tools and documentation surrounding TLS, which should be sufficient to solve the majority of people's problems. I have no intention of introducing less widely-used protocols, as this would make it very difficult to integrate with other tools/proxies.

That's fair enough, thought rathole also supports TLS for those who want it. Having the extra simpler option for those who'd prefer it is something I think a lot of people could like though, especially for hobbyists who are experimenting around with a homelab.

My setup really does just involve wanting to keep things simple, it looks like the Noise procotol is fairly popular though if that's any argument towards it.

By the way, if you need to encrypt and avoid transmitting tokens in plain text, in the new version, you actually don't need to do any configuration. This is the default behavior.

A middle-man would still be able to intercept an entire connection though, right? From what I understood things get encrypted with the setup you were talking about, but the server doesn't verify itself on the initial connect still.

I'd like to add that I would like to still consider frp as an option for me, it's popularity is definitely a really good benefit to use it. It won't bother me too much if this isn't a direction you'd like to have for the project though, I'm just throwing this all out to get some ideas out.

@hwittenborn commented on GitHub (Jul 20, 2023): > I feel that there are already plenty of tools and documentation surrounding TLS, which should be sufficient to solve the majority of people's problems. I have no intention of introducing less widely-used protocols, as this would make it very difficult to integrate with other tools/proxies. That's fair enough, thought rathole also supports TLS for those who want it. Having the extra simpler option for those who'd prefer it is something I think a lot of people could like though, especially for hobbyists who are experimenting around with a homelab. My setup really does just involve wanting to keep things simple, it looks like the Noise procotol is [fairly popular](https://duo.com/labs/tech-notes/noise-protocol-framework-intro#section7) though if that's any argument towards it. > By the way, if you need to encrypt and avoid transmitting tokens in plain text, in the new version, you actually don't need to do any configuration. This is the default behavior. A middle-man would still be able to intercept an entire connection though, right? From what I understood things get encrypted with the setup you were talking about, but the server doesn't verify itself on the initial connect still. I'd like to add that I would like to still consider frp as an option for me, it's popularity is definitely a really good benefit to use it. It won't bother me too much if this isn't a direction you'd like to have for the project though, I'm just throwing this all out to get some ideas out.

gitea-mirror commented

2026-05-05 13:48:56 -06:00

Author

Owner

@hwittenborn commented on GitHub (Jul 20, 2023):

Just another note I'm throwing out, but I do think there's value in the simplicity of only needing to run one command for newbies who know nothing about generating TLS certificates (which was pretty much me until I had to with frp, as all the certs I previously managed were done through certbot). There's just a lot less you have to run, and likewise a lot less you can get wrong.

I know people running a proxy should probably know what they're doing, but I don't think it ever hurts to increase the newbie-friendliness through things like this.

@hwittenborn commented on GitHub (Jul 20, 2023): Just another note I'm throwing out, but I do think there's value in the simplicity of only needing to run one command for newbies who know nothing about generating TLS certificates (which was pretty much me until I had to with frp, as all the certs I previously managed were done through `certbot`). There's just a lot less you have to run, and likewise a lot less you can get wrong. I know people running a proxy should probably know what they're doing, but I don't think it ever hurts to increase the newbie-friendliness through things like this.

gitea-mirror commented

2026-05-05 13:48:57 -06:00

Author

Owner

@fatedier commented on GitHub (Jul 20, 2023):

I have a plan to implement automatic certificate application and renewal through https://github.com/go-acme/lego.

I'm not sure how many users like you want to avoid middle-man attacks but also don't want to use TLS. If there is a widespread demand, perhaps we can consider it.

@fatedier commented on GitHub (Jul 20, 2023): I have a plan to implement automatic certificate application and renewal through `https://github.com/go-acme/lego`. I'm not sure how many users like you want to avoid middle-man attacks but also don't want to use TLS. If there is a widespread demand, perhaps we can consider it.

Rows
Columns

[GH-ISSUE #3515] How to set up Lets Encrypt for server verification? #2806

Bug Description

frpc Version

frps Version

System Architecture

Configurations

Logs

Steps to reproduce

Affected area