marcel/zoraxy
1
0
Fork 0
mirror of https://github.com/tobychui/zoraxy.git synced 2025-06-01 13:17:21 +02:00
Code Issues Packages Projects Releases Wiki Activity

Added certificate migrate guide

Toby Chui 2024-04-26 11:37:15 +08:00
parent 338b29135c
commit 34f9d656c1
1 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
Migrating-Certificates-From-Other-Systems.md Normal file

@ -0,0 +1,42 @@
Let say you have another reverse proxy server running and you want to switch over to Zoraxy due to some bugs that they never resolve or you just wanna try out Zoraxy, here is the short guide on how to migrate your certificates to Zoraxy.
### Migrate Certificates
1. Stop Zoraxy (e.g. `sudo systemctl stop zoraxy` or just close the terminal window if you are running on Windows)
2. Copy all the certificates previously generated by another reverse proxy server into your certs folder. The certs folder are usually located in `/conf/certs/`
3. Rename your certs according to the Certificate Naming Scheme below
4. Start Zoraxy (e.g. `sudo systemctl start zoraxy`)
### Certificate Naming Scheme
The certificates should be in `.key` and `.pem` file extensions. The key file is the private key and the pem file is the public key.
#### Single Hostname Certificates
For the filename of the key files, make sure your private key and public key have the same filename and the filename matches your host name in HTTP proxy rule. For example, you have a HTTP proxy rule that route example.com, you should name your key-pairs for this route as
```
example.com.key
example.com.pem
```
#### Wildcard Certificates
If you have a wildcard certificate and want to use them for multiple HTTP proxy rule, you can use the longest common suffix of both rules as the filename of the key-pairs. For example, you have two HTTP proxy rule that route `a.example.com` and `b.example.com`, and you have a certificate that covers `*.example.com`, you can name the key-pairs as follows.
```
example.com.key
example.com.pem
```
The same rules goes for 3 / 4 level sub-domains. For example, `a.server.example.com` and `b.server.example.com` with a certificate that covers `*.server.example.com`, you can name your certificates as follows.
```
server.example.com.key
server.example.com.pem
```
#### Multi-hostname Certificates (SAN Certificates)
If you have a SAN certificates that contain multiple host-name in the CN field, you can name it to the any of the hostname in the CN field. For example, you have a certificate that covers `mydomain.com` , `example.com` and `anotherdomain.com`, where most of your traffic come from mydomain.com, you can name your certificates as follows.
```
mydomain.com.key
mydomain.com.pem
```
Once Zoraxy cannot get a direct hit on searching the registered certificate, it will start checking if which certificates contains a CN host-name that matches the current SNI provided hostname. Generally speaking, you can name it to anything you want. For high traffic sites, although there are cache and in-memory lookup map in place, it would still save a bit CPU cycles if you use the first / most commonly used hostname as the filename.