Connect through a domain name
Out of the box, the server presents a self-signed certificate with a made-up name, and its access keys lead to its IP address. Give it a domain name you own, with a certificate from a certificate authority, and a connection to it looks like a visit to an ordinary website.
What a domain changes
Keys made after the change carry the domain. Apps look it up when they connect and check the server's certificate the way a browser does, so if you move the server to a new IP address, you point the domain at it and those keys keep working.
The keys still carry the server's IP addresses too, so an app that cannot look the domain up connects as before.
Before you start
- A domain or a subdomain you control, such as
vpn.example.com. Use a single name, not a wildcard. - A DNS record that points it at the server's connection IP: an A record, and an AAAA record if the server has an IPv6 address. Point it straight at the server, not through a CDN's proxy.
- On a managed server, TCP port
80open, for as long as you use the domain: the certificate is checked through it, and renewed through it every few months.
On a managed server
- In VpnHood! MANAGER, open Server Farms and then the farm. Under SSL / TLS Certificates, select Add, enter the domain as Domain Name and select Create. MANAGER creates a self-signed certificate for it and opens it.
- Edit Signing and choose AutoSign. MANAGER asks Let's Encrypt for a certificate, which checks the domain through your server on TCP port
80. When it is done, Signature reads CA Signed, and MANAGER renews the certificate by itself before it expires. - Then edit Visibility and choose PublicInToken. Every key of the farm now carries the domain, and the farm's previous certificate becomes Public.
Keys you copy from MANAGER from now on carry the domain. Apps holding an older key get the new one when they connect, as Push token to clients is on by default. Keep the farm's previous certificate until then: older keys work only while it is there.
If the check fails, Signing shows why, and after a few failed attempts it goes back to Manual. Fix the DNS record or open the port, then choose AutoSign again.
To check, open the farm: under Access Points, the domain comes first.
A server's own page has a SSL / TLS Certificates list too. A certificate there belongs to that one server, so add the domain your keys carry to the farm instead.
On a standalone server
A standalone server cannot get a certificate by itself. Get one for the domain from a certificate authority, as a PFX file with its private key, and put it in place of /opt/VpnHoodServer/storage/access/certificates/default.pfx, under the same name.
Then put the file's password in SslCertificatesPassword and set IsValidHostName to true, both under FileAccessManager in /opt/VpnHoodServer/storage/appsettings.json. A new install has no such file: create it, and from then on the server uses it in place of the settings it was installed with.
The whole file, with your certificate's password in place of the example
{
"FileAccessManager": {
"SslCertificatesPassword": "your-pfx-password",
"IsValidHostName": true
},
"ServerConfig": {
"LogAnonymizer": true,
"AddListenerIpsToNetwork": "*"
},
"LogLevel": "Information"
}The server takes the domain from the certificate itself, so there is no setting for it.
Restart the server with sudo systemctl restart VpnHoodServer, or with sudo docker restart VpnHoodServer in Docker. With a wrong password it does not start, and its log says The server could not start.
Keys made before the change stop working, as they expect the old certificate. Print each of them again and give your users the new key: its options and its usage stay the same. A key's ID is the name of its file in /opt/VpnHoodServer/storage/access, without .token2.
List the keys, then print one again by its ID
sudo ls /opt/VpnHoodServer/storage/access
sudo /opt/VpnHoodServer/vhserver print 2b9d4a6e-1c3f-4e8a-9b7d-5f0e8c2a1d34In Docker, run the same through sudo docker exec VpnHoodServer /app/vhsupervisor, as for vhserver gen.
The new keys carry the domain and no longer depend on the certificate itself, so they keep working when you renew it: put the new file in place and restart the server.
