Showing posts with label openvpn. Show all posts
Showing posts with label openvpn. Show all posts

Friday, August 2, 2019

Renew your wildcard certificate on your DSM Webstation and OpenVPN server

Are you having a wildcard (*.yourdomain.com) SSL certificate that is expiring and needs a renewal? Below are the steps to take to renew it on a Synlogy DSM. I also use the certificate for the OpenVPN server on the DSM. So I need to update it twice.

Convention:

  • Certificate: server.crt
  • Private key: server.key
  • Intermediate: ca_bundle.crt
  • Root: ca.crt


Receive a new wildcard certificate

  • Login in DSM https://ip:5001
  • SSH into the DSM
  • cd /usr/syno/etc/packages/VPNCenter/openvpn/keys
  • copy the ca_bundle.crt file
  • In the DSM: Control Panel > Security > Certificate
  • Click on CSR, then renew certificate
  • Select the Country and download CSR and the private key.
  • Go to ssl2buy.com to buy a new wildcard certificate from alphassl.com
  • Enter the CSR (generated by your DSM) and select approval method admin@yourdomain.com
  • Go to your webmail and login with the admin@yourdomain.com account to check for the email to approve your new purchase
  • Click on the approval email request to issue out the certificate (you get an email with the certificate from ssl2buy)
  • Add a new certificate by entering the server.key, server.crt and ca_bundle.crt files in the wizard
  • Click on Edit to set the new certificate as the Default one, then remove the old (inactive) one. The webserver should restart itself now with the new certificate
Tip: The intermediate certificate (in base64 format) from AlphaSSL can be downloaded here


Update the certificates for the OpenVPN server

  • SSH into the DSM and make yourself root
  • sudo -i
    cd /usr/syno/etc/packages/VPNCenter/openvpn/keys
  • Make a new folder for the last time you created/renewed your certificate under "history" directory. Move the (old) certificates there to as a backup.
  • mkdir history/YYYY-MM-DD
    mv server.* history/YYYY-MM-DD
    cp -rp ca* history/YYYY-MM-DD
  • Add the new private key, certificate and intermediate by doing vi server.key ... Do this for the 2 server files mentioned under Convention.
  • Make the files owner readable only
  • chmod 400 server*
    chmod 400 ca*
  • Restart the OpenVPN server
  • /var/packages/VPNCenter/target/scripts/openvpn.sh restart


And you should be good to go for another year...

Thursday, March 23, 2017

OpenVPN: unable to get local issuer certificate

I was running into the below issue after updating my server certificate on my OpenVPN server:

Wed Mar 22 10:05:14 2017 us=60205 VERIFY ERROR: depth=1, error=unable to get local issuer certificate: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Wed Mar 22 10:05:14 2017 us=60205 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Wed Mar 22 10:05:14 2017 us=61205 TLS_ERROR: BIO read tls_read_plaintext error

Broader log:

Wed Mar 22 10:05:12 2017 us=848205 Local Options String: 'V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Wed Mar 22 10:05:12 2017 us=848205 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Wed Mar 22 10:05:12 2017 us=848205 Local Options hash (VER=V4): 'XXXXXXXX'
Wed Mar 22 10:05:12 2017 us=848205 Expected Remote Options hash (VER=V4): 'XXXXXXXX'
Wed Mar 22 10:05:12 2017 us=848205 Attempting to establish TCP connection with [AF_INET]A.B.C.D:1200 [nonblock]
Wed Mar 22 10:05:12 2017 us=848205 MANAGEMENT: >STATE:1490173512,TCP_CONNECT,,,
Wed Mar 22 10:05:13 2017 us=849205 TCP connection established with [AF_INET]A.B.C.D:1200
Wed Mar 22 10:05:13 2017 us=849205 TCPv4_CLIENT link local: [undef]
Wed Mar 22 10:05:13 2017 us=849205 TCPv4_CLIENT link remote: [AF_INET]A.B.C.D:1200
Wed Mar 22 10:05:13 2017 us=849205 MANAGEMENT: >STATE:1490173513,WAIT,,,
Wed Mar 22 10:05:13 2017 us=909205 MANAGEMENT: >STATE:1490173513,AUTH,,,
Wed Mar 22 10:05:13 2017 us=909205 TLS: Initial packet from [AF_INET]A.B.C.D:1200, sid=bb2bb206 e079c6ed
Wed Mar 22 10:05:14 2017 us=60205 VERIFY ERROR: depth=1, error=unable to get local issuer certificate: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Wed Mar 22 10:05:14 2017 us=60205 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Wed Mar 22 10:05:14 2017 us=61205 TLS_ERROR: BIO read tls_read_plaintext error
Wed Mar 22 10:05:14 2017 us=61205 TLS Error: TLS object -> incoming plaintext read error
Wed Mar 22 10:05:14 2017 us=61205 TLS Error: TLS handshake failed

The root cause was that the root certificate AND intermediate certificate have to be added into the client's configuration file.

So this has to look like this to work properly:

-----BEGIN CERTIFICATE-----
YOUR ROOT CERTIFICATE
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
YOUR INTERMEDIATE CERTIFICATE
-----END CERTIFICATE-----



Tuesday, January 10, 2017

Installing SSLH onto Synology DSM6 or DSM7 for easy HTTPS, OpenVPN and SSH through corporate firewall

When you are in a corporate LAN, access to the outside is often restricted. HTTPS is allowed, yet other applications like SSH or OpenVPN might not be. As well, you want to run several of these services onto your Synology box. Choosing which one will use TCP port 443 could be a hard judgement to make. Luckily, there is SSLH to the rescue.

Note: with DSM7, it is no longer possible by default to open port 443 (which is below 1024) with the provided user (sh-sslh). You will get a "0.0.0.0:https:bind: Permission denied" error when changing port 30000 to 443. The fix is to change your portforwarding in your router to NAS_IP:30000 instead. The below tutorial was making the SSLH service listen to port 443 with the other services running on localhost:443.

 As a consequence, changing the sslh.cfg file and the NGINX files is no longer needed, so everything below can be ignorred.

Caution! Playing around with your SSL port could possibly break the access to your DSM if nginx fails to restart.
Therefore, I strongly recommend the following actions:

  • Never put your SSH server to listen ONLY onto 127.0.0.1. Never.
  • Never change all of your services (HTTPS, SSH, OpenVPN) at the same time, unless your 100% sure your config is correct.
  • Open up temporarily the Telnet service, just in case
  • Make sure you don't lock yourself out with your firewall rules onto your Synology
  • Backup the original config files before starting making changes. cp -p config.file config.file.ori will do.

0. Make sure you have the Synocommunity repository installed under your Package Center. Open up an SSH connection to your Synology and make yourself root.
1. Download and install the SSLH package. By default, the configuration file is at /usr/local/sslh/var/sslh.cfg and needs to be adapted. Make a backup copy of the file first.
2. Go to your terminal and edit the file with vi
vi /usr/local/sslh/var/sslh.cfg
3. Change the IP address (under host: "0.0.0.0") to your IPv4 address of the Synology. Do NOT yet change the port. Leave it onto 30000 as default.
4. Check if the services listed are using the correct port numbers and adapt if needed. Save the file.
5. Now go to the Package Center of DSM again and stop and start SSLH.
6. Go to your terminal and verify if SSLH is running properly by running the command:
netstat -an | grep 30000
Expected output:
root@server:/# netstat -an | grep 30000
tcp        0      0 192.168.0.5:30000       0.0.0.0:*               LISTEN
7. Check if HTTPS is currently running and listening to the IPv4 address:
netstat -an | grep 443
Expected output:
root@server:/# netstat -an | grep 443
tcp        0      0 0.0.0.0:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
This now means that nginx is still listening onto the IPv4 address for HTTPS. Let's change that.
8. Open your web browser and browse to your Synology IP for both HTTP as for HTTPS: http://yourip and https://yourip
Confirm that this is working properly.
9. Go to the nginx config directory (/usr/syno/share/nginx) and backup the following files: DSM.mustache, WWWService.mustache and server.mustache
10. Use vi to change nginx from listening to 0.0.0.0:443 to 127.0.0.1:443 only, by making it look like this:
listen 127.0.0.1:443

DSM.mustache
WWWService.mustache
server.mustache
Repeat this for all 3 files and save your changes.
11. Restart nginx from the command line:
synoservicecfg --restart nginx
You can monitor into /var/log/synoservice.log if things restarted properly. Typical output should be:
2017-01-10T19:04:33+01:00 server synoservicecfg: service_restart.c:21 synoservice: restart [nginx] ...
2017-01-10T19:04:34+01:00 server synoservicecfg: service_restart.c:52 synoservice: finish restart [nginx].
12. Verify that HTTPS is only listening onto localhost (127.0.0.1)
root@server:/usr/syno/share/nginx# netstat -an | grep 443
tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
13. Refresh the browser screen for your HTTPS. It should not show any website anymore.
14. As a final step, change your SSLH config file and set the port to listen from 30000 to 443. Restart SSLH in the Package Center by doing a stop and start. Or do it command line:
synoservicecfg --restart pkgctl-sslh
15. Verify that SSLH is now listening onto your IPv4 address with port 443.
root@server:/usr/syno/share/nginx# netstat -an | grep 443
tcp        0      0 192.168.0.5:443         0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
16. You can test your HTTPS, OpenVPN and SSH. All should perfectly route through the SSLH multiplexer.