Fossil SCM
Tweaks to the SSL server documentation.
Commit
2e2da5783d00665ace94417ac848ef45878af3b1dac00ab46426ffe326641a41
Parent
44f4d624f11071f…
1 file changed
+8
-7
+8
-7
| --- www/ssl-server.md | ||
| +++ www/ssl-server.md | ||
| @@ -20,11 +20,11 @@ | ||
| 20 | 20 | * "[fossil http](/help?cmd=http)" |
| 21 | 21 | |
| 22 | 22 | now all handle server-mode SSL/TLS encryption natively. It is now possible |
| 23 | 23 | to run a secure Fossil server without having to put Fossil behind an encrypting |
| 24 | 24 | web server or reverse proxy. Hence, it is now possible to stand up a complete |
| 25 | -Fossil project set on an inexpensive VPS with no added software other than | |
| 25 | +Fossil project website on an inexpensive VPS with no added software other than | |
| 26 | 26 | Fossil itself and something like [certbot](https://certbot.eff.org) for |
| 27 | 27 | obtaining a CA-signed certificate. |
| 28 | 28 | |
| 29 | 29 | ## Usage |
| 30 | 30 | |
| @@ -98,11 +98,11 @@ | ||
| 98 | 98 | `-----END CERTIFICATE-----` |
| 99 | 99 | |
| 100 | 100 | In both formats, text outside of the delimiters is ignored. That means |
| 101 | 101 | that if you have a PEM-formatted private key and a separate PEM-formatted |
| 102 | 102 | certificate, you can concatenate the two into a single file and the |
| 103 | -individual components will still be readily accessible. | |
| 103 | +individual components will still be easily accessible. | |
| 104 | 104 | |
| 105 | 105 | If you have a single file that holds both your private key and your |
| 106 | 106 | cert, you can hand it off to the "[fossil server](/help?cmd=server)" |
| 107 | 107 | command using the --tls-cert-file option. Like this: |
| 108 | 108 | |
| @@ -109,21 +109,22 @@ | ||
| 109 | 109 | > ~~~ |
| 110 | 110 | fossil server --port 443 --tls-cert-file mycert.pem /home/www/myproject.fossil |
| 111 | 111 | ~~~ |
| 112 | 112 | |
| 113 | 113 | The command above is sufficient to run a fully-encrypted web site for |
| 114 | -the "myproject.fossil" Fossil repository. This command must be root as | |
| 114 | +the "myproject.fossil" Fossil repository. This command must be run as | |
| 115 | 115 | root, since it wants to listen on TCP port 443, and only root processes are |
| 116 | 116 | allowed to do that. This is safe, however, since before reading any |
| 117 | 117 | information off of the wire, Fossil will put itself inside a chroot jail |
| 118 | 118 | at /home/www and drop all root privileges. |
| 119 | 119 | |
| 120 | 120 | ## The ACME Protocol |
| 121 | 121 | |
| 122 | -The [ACME Protocol][2] is used to prove to a CA that you really control a | |
| 123 | -website so that the CA will issue a cert for you. The usual means of | |
| 124 | -dealing with ACME is to run the separate [certbot](/certbot.eff.org) tool. | |
| 122 | +The [ACME Protocol][2] is used to prove to a CA that you control a | |
| 123 | +website. CAs require proof that you control a domain before they | |
| 124 | +will issue a cert for that domain. The usual means of dealing | |
| 125 | +with ACME is to run the separate [certbot](/certbot.eff.org) tool. | |
| 125 | 126 | Here is, in a nutshell, what certbot will do to obtain your cert: |
| 126 | 127 | |
| 127 | 128 | 1. Certbot sends your "signing request" (the document that contains |
| 128 | 129 | your public key and your domain name) to the CA. |
| 129 | 130 | |
| @@ -144,11 +145,11 @@ | ||
| 144 | 145 | |
| 145 | 146 | In order for all of this to happen, certbot needs to be able to create |
| 146 | 147 | a subdirectory named ".well-known", within a directory you specify, and |
| 147 | 148 | then populate that subdirectory with a token file of some kind. To support |
| 148 | 149 | this, the "[fossil server](/help?cmd=server)" and |
| 149 | -"[fossil http](/help?cmd=http)" commands support the --acme option. | |
| 150 | +"[fossil http](/help?cmd=http)" commands have the --acme option. | |
| 150 | 151 | When the --acme option is specified and Fossil sees a URL where the path |
| 151 | 152 | begins with ".well-known", then instead of doing its normal processing, it |
| 152 | 153 | looks for a file with that pathname and returns it to the client. If |
| 153 | 154 | the "server" or "http" command is referencing a single Fossil repository, |
| 154 | 155 | then the ".well-known" sub-directory should be in the same directory as |
| 155 | 156 |
| --- www/ssl-server.md | |
| +++ www/ssl-server.md | |
| @@ -20,11 +20,11 @@ | |
| 20 | * "[fossil http](/help?cmd=http)" |
| 21 | |
| 22 | now all handle server-mode SSL/TLS encryption natively. It is now possible |
| 23 | to run a secure Fossil server without having to put Fossil behind an encrypting |
| 24 | web server or reverse proxy. Hence, it is now possible to stand up a complete |
| 25 | Fossil project set on an inexpensive VPS with no added software other than |
| 26 | Fossil itself and something like [certbot](https://certbot.eff.org) for |
| 27 | obtaining a CA-signed certificate. |
| 28 | |
| 29 | ## Usage |
| 30 | |
| @@ -98,11 +98,11 @@ | |
| 98 | `-----END CERTIFICATE-----` |
| 99 | |
| 100 | In both formats, text outside of the delimiters is ignored. That means |
| 101 | that if you have a PEM-formatted private key and a separate PEM-formatted |
| 102 | certificate, you can concatenate the two into a single file and the |
| 103 | individual components will still be readily accessible. |
| 104 | |
| 105 | If you have a single file that holds both your private key and your |
| 106 | cert, you can hand it off to the "[fossil server](/help?cmd=server)" |
| 107 | command using the --tls-cert-file option. Like this: |
| 108 | |
| @@ -109,21 +109,22 @@ | |
| 109 | > ~~~ |
| 110 | fossil server --port 443 --tls-cert-file mycert.pem /home/www/myproject.fossil |
| 111 | ~~~ |
| 112 | |
| 113 | The command above is sufficient to run a fully-encrypted web site for |
| 114 | the "myproject.fossil" Fossil repository. This command must be root as |
| 115 | root, since it wants to listen on TCP port 443, and only root processes are |
| 116 | allowed to do that. This is safe, however, since before reading any |
| 117 | information off of the wire, Fossil will put itself inside a chroot jail |
| 118 | at /home/www and drop all root privileges. |
| 119 | |
| 120 | ## The ACME Protocol |
| 121 | |
| 122 | The [ACME Protocol][2] is used to prove to a CA that you really control a |
| 123 | website so that the CA will issue a cert for you. The usual means of |
| 124 | dealing with ACME is to run the separate [certbot](/certbot.eff.org) tool. |
| 125 | Here is, in a nutshell, what certbot will do to obtain your cert: |
| 126 | |
| 127 | 1. Certbot sends your "signing request" (the document that contains |
| 128 | your public key and your domain name) to the CA. |
| 129 | |
| @@ -144,11 +145,11 @@ | |
| 144 | |
| 145 | In order for all of this to happen, certbot needs to be able to create |
| 146 | a subdirectory named ".well-known", within a directory you specify, and |
| 147 | then populate that subdirectory with a token file of some kind. To support |
| 148 | this, the "[fossil server](/help?cmd=server)" and |
| 149 | "[fossil http](/help?cmd=http)" commands support the --acme option. |
| 150 | When the --acme option is specified and Fossil sees a URL where the path |
| 151 | begins with ".well-known", then instead of doing its normal processing, it |
| 152 | looks for a file with that pathname and returns it to the client. If |
| 153 | the "server" or "http" command is referencing a single Fossil repository, |
| 154 | then the ".well-known" sub-directory should be in the same directory as |
| 155 |
| --- www/ssl-server.md | |
| +++ www/ssl-server.md | |
| @@ -20,11 +20,11 @@ | |
| 20 | * "[fossil http](/help?cmd=http)" |
| 21 | |
| 22 | now all handle server-mode SSL/TLS encryption natively. It is now possible |
| 23 | to run a secure Fossil server without having to put Fossil behind an encrypting |
| 24 | web server or reverse proxy. Hence, it is now possible to stand up a complete |
| 25 | Fossil project website on an inexpensive VPS with no added software other than |
| 26 | Fossil itself and something like [certbot](https://certbot.eff.org) for |
| 27 | obtaining a CA-signed certificate. |
| 28 | |
| 29 | ## Usage |
| 30 | |
| @@ -98,11 +98,11 @@ | |
| 98 | `-----END CERTIFICATE-----` |
| 99 | |
| 100 | In both formats, text outside of the delimiters is ignored. That means |
| 101 | that if you have a PEM-formatted private key and a separate PEM-formatted |
| 102 | certificate, you can concatenate the two into a single file and the |
| 103 | individual components will still be easily accessible. |
| 104 | |
| 105 | If you have a single file that holds both your private key and your |
| 106 | cert, you can hand it off to the "[fossil server](/help?cmd=server)" |
| 107 | command using the --tls-cert-file option. Like this: |
| 108 | |
| @@ -109,21 +109,22 @@ | |
| 109 | > ~~~ |
| 110 | fossil server --port 443 --tls-cert-file mycert.pem /home/www/myproject.fossil |
| 111 | ~~~ |
| 112 | |
| 113 | The command above is sufficient to run a fully-encrypted web site for |
| 114 | the "myproject.fossil" Fossil repository. This command must be run as |
| 115 | root, since it wants to listen on TCP port 443, and only root processes are |
| 116 | allowed to do that. This is safe, however, since before reading any |
| 117 | information off of the wire, Fossil will put itself inside a chroot jail |
| 118 | at /home/www and drop all root privileges. |
| 119 | |
| 120 | ## The ACME Protocol |
| 121 | |
| 122 | The [ACME Protocol][2] is used to prove to a CA that you control a |
| 123 | website. CAs require proof that you control a domain before they |
| 124 | will issue a cert for that domain. The usual means of dealing |
| 125 | with ACME is to run the separate [certbot](/certbot.eff.org) tool. |
| 126 | Here is, in a nutshell, what certbot will do to obtain your cert: |
| 127 | |
| 128 | 1. Certbot sends your "signing request" (the document that contains |
| 129 | your public key and your domain name) to the CA. |
| 130 | |
| @@ -144,11 +145,11 @@ | |
| 145 | |
| 146 | In order for all of this to happen, certbot needs to be able to create |
| 147 | a subdirectory named ".well-known", within a directory you specify, and |
| 148 | then populate that subdirectory with a token file of some kind. To support |
| 149 | this, the "[fossil server](/help?cmd=server)" and |
| 150 | "[fossil http](/help?cmd=http)" commands have the --acme option. |
| 151 | When the --acme option is specified and Fossil sees a URL where the path |
| 152 | begins with ".well-known", then instead of doing its normal processing, it |
| 153 | looks for a file with that pathname and returns it to the client. If |
| 154 | the "server" or "http" command is referencing a single Fossil repository, |
| 155 | then the ".well-known" sub-directory should be in the same directory as |
| 156 |