I'm creating this post for other potentially frustrated users following the instructions from the wiki on how to create certificates and use for SSTP tunneling (see http://wiki.mikrotik.com/wiki/Manual:Cr ... rtificates). We attempted to do the following:

/certificate
add name=ca-template common-name=myCa key-usage=key-cert-sign,crl-sign
add name=server-template common-name=server
add name=client1-template common-name=client1

However, after importing the certificates to their appropriate locations, we could not establish the connection when the "Verify Server Certificate" was checked, despite the fact the same CA was used for the client and server certificates.

On this webpage, https://www.medo64.com/2017/01/simple-s ... -mikrotik/, the author showed a slightly modified approach to creating the certificate templates:

/certificate
add name=ca-template common-name=example.com days-valid=3650 key-size=2048 key-usage=crl-sign,key-cert-sign
add name=server-template common-name=*.example.com days-valid=3650 key-size=2048 key-usage=digital-signature,key-encipherment,tls-server
add name=client-template common-name=client.example.com days-valid=3650 key-size=2048 key-usage=tls-client

As you will note, he included key-usage values for the server and client templates. After doing this, and following the same subsequent steps, we were able to establish the secure link.

I hope this saves others a bit of time troubleshooting. It would be nice to update the mikrotik wiki page with the above as well (though not sure how to do this).

Most commonly required key-usages are set by default if not specified manually. so there is no need to explicitly specify key usages, unless you need something very specific.

Most commonly required key-usages are set by default if not specified manually. so there is no need to explicitly specify key usages, unless you need something very specific.

Hmmm. Just recreated the certs and you're absolutlely right. Each cert has digital signature, key encipherment, data encipherment, key cert. sign, crl sign, tls client and tls server. Could the problem be the presence of one of these? Could the crl sign on the client block the handshake?

No, that key usage simply allows to sing CRLs. It is highly unlikely that key usage caused the problem. Most likely problem was verify-server-certificate and verify-server-address options.

If both are enabled then connect-to address must match common-name or subj-alt-name of server certificate.