I changed the SSTP server certificate from RSA 2048 to EC secp384r1, and the client is getting an ssl: fatal alert handshake (6) error. Has anyone else experienced this issue?
I haven’t seen this exact issue but, have you tried setting up SSTP on a different client to see if it can connect (SSTP is available for Linux and works nicely)?
–
Backups are your friend. Always make a backup!
/system backup save encryption=aes-sha256 name=MyBackup
Please, export and attach your current config to your post if you want help with a config issue:
/export hide-sensitive file=MyConfig
It does work fine with the RSA certificate. Therefore I conceive the certificate key type plays a role in the error. Furthermore, the EC certificate works well with the www-ssl service and user manager.
I have also tried a Windows SSTP client connection without success.
The user SYSTEM dialed a connection named SSTP which failed. The error code returned on failure is -2146893018.
Regards,
That is what I was thinking. Unfortunately the error code doesn’t seem to give any useful information but, at a guess, either EC secp384r1 isn’t supported by Windows or, possibly, it isn’t enabled by default. Take a look at these two pages to see which ciphers MS supports by default and supports but needs to be enabled.
One day, I hope, MS will give error codes and messages that make some sense.
The goal is to establish an SSTP tunnel between two Mikrotik endpoints.
Does RouterOS support the EC certificate on the SSTP server?
The SSL fatal alert handshake error can occur when trying to connect to a Secure Socket Tunneling Protocol (SSTP) server. Here are some tips to help fix this error:
Check the firewall settings: Make sure that the firewall on the client computer is not blocking the SSTP traffic. You can also try temporarily disabling the firewall to see if it resolves the issue.
Check the SSL certificate: Ensure that the SSL certificate installed on the SSTP server is valid and not expired. You can also try importing the SSL certificate on the client computer.
Update the client computer: Ensure that the client computer is running the latest updates and patches for the operating system and SSTP client software.
Regards,
Rachel Gomez
Short answer: I don’t know. My experience is with getting Windows clients to connect to an SSTP server running on a MikroTik.
How are you generating the certificates for the SSTP server? Are those certificates marked as trusted on both ends (if they’re not from a trusted CA)?
I’ve had a lot of trouble when using self-signed certificates or certificates signed by a MikroTik Router setup as a CA. The trust problems were solved by importing the public certificate (and/or CA public certificate) to the client device and marking it as trusted.
How are you generating the certificates for the SSTP server?
Let’s Encrypt & CF API
Are those certificates marked as trusted on both ends (if they’re not from a trusted CA)?
Yes
OK, now I’m just making guesses based on what I’ve read.
On the SSTP Server: Do you have Force AES enabled? If you do, Windows clients won’t be able to connect (Windows only supports RC4). <== This will mess up you trying to test the connection from a Windows client.
On the SSTP Client: Are you trying to connect using the IP address rather than the FQDN? Let’s Encrypt doesn’t support using IPs in their certficates (based on what I last read on their site).
I hope you manage to track down the issue. Please let us know when you do and how you fixed it.
No, I await for response in the forum. If no progress is achieved here, I will raise a support ticket.
Force AES
It doesn’t have this on V7. Both the PFS option and clients’ certificate verification were disabled.
FQDN? Let’s Encrypt doesn’t support using IPs in their certificates.
Yes, I used FQDN.
Any solution? I have same problem here.
Solution found: let’sencrypt, as default, generate ECDSA key, unsupporte by mikrotik. Use --keytype rsa on certbot command to generate a let’sencrypt RSA key, that works on mikrotik.
Thank you for taking the time and document it. However, if one creates the certificate with MT “/certificate enable-ssl-certificate dns-name=FQDN”. The generated certificate is compatible with MT, which is an RSA one. Although, I wanted to use my EC certificate.
I tried the same. SSTP server doesn’t works with EC certs, however it works if client uses EC cert and server uses RSA cert.