I try to setup an Mikrotik CHR Instance for maintaining an admin vpn between mikrotik hardware.
For connecting from clients (e.g. RB2011) to the server I’m using SSTP because i think it will have the fewest nat, firewall, etc. issues. The CHR instance has a valid hostname and rdns (chr.valid.com) and i got a certificate from let’s encrypt for this hostname. On the client side i have two options to check the server certificate (Verify Server Certificate/ Verify Server Address from Certificate). When i enable Verify Server Certificate i get an error message self-signed certificate in certificate chain. When I disable this check, the Client connects correctly. But using an invalid hostname (e.g. chr.untrusted.com) which points to the server. The Clients also connects to the server.
In my understanding this opens the possibility for a man-in-the-middle-attack by routing the the traffic to another server. Am i correct that Verify Server Address from Certificate only checks if the given certificate matches the offered certificate name and does no certificate verification? What is the correct way to tell the mikrotik client to connect only to a server with valid certificate (valid = correct server certificate)?
AFAIK Verify Server Address from Certificate does nothing if Verify Server Certificate is disabled.
The error message self-signed certificate in certificate chain most likely indicates you have not installed the certificate chain - on the server you should have: Let’s Encrypt root CA cert, any intermediate CA cert, your cert + private key, and on the client you should have: Let’s Encrypt root CA cert.
Thanks for you reply. I tried to import the the root certificate into the client, but the error message is the same.
Client:
Server:
Even if i import the lets encrypt certificate for the server directly i get the error message.
Well, thats my problem. I checked the offered cert with openssl. The server is sending the correct one. Windows 10 Clients has no problem with connecting. But Mikrotik-Client doesn’t trust it.
openssl s_client -connect vpn.example.net:443
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = vpn.example.net
verify return:1
---
Certificate chain
0 s:/CN=vpn.example.net
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
2 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
xxx——END CERTIFICATE-----
subject=/CN=vpn.exmaple.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3991 bytes and written 798 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-SHA
Session-ID: xxx
Session-ID-ctx:
Master-Key: xxx
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 98 0b 10 84 0c dc 6f 97-11 51 e5 c7 4b f1 3a 62 ......o..Q..K.:b
0090 - d2 c5 66 46 2e 37 e7 6a-6a b1 2d c9 ec 54 28 3d ..fF.7.jj.-..T(=
Start Time: 1559159026
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
It appears that as Let’s Encrypt is fairly new in the certificate world their certificates were cross-signed by an established CA so they would be recognised by browsers which already had the established CA certificate.
Now that the Let’s Encrypt CA has made its way into trusted CA bundles (in OS and browsers) at some point newly issued certificates will be signed with their own CA. So, it would be wise to install both CAs (TrustID X3 Root and ISRG X1 Root) so current and future server certificates can be verified by the client Mikrotik.
