That should change in the future. There's already LE client in ROSv7, but so far only for www service. I didn't test it, but you can probably write a script to reuse the same certificate for SSTP. But you still need www service running and accessible from internet, which may not be what you want. But since most of the work is done, it shouldn't be too hard to make it into something more universally usable. Add some hooks for custom scripts. Allow dns verification (which would still require external servers, but it would help with some scenarios). I'm almost sure that it will happen eventually, but since it's not high priority feature, it may take a while.

@anav: That's a problem with certificates, they are very secure when everything is configured correctly, but to do that can be quite annoying and tricky. You always have to verify them, otherwise they are useless.

Self-signed certificates can be as secure as trusted ones, in a way even more secure (*). But only with correct verification, which means that every single client must be given either server's certificate, or certificate of your custom CA used to issue server's certificate. Then client can verify that there's really no MITM. Trouble is, this is ok if you do it for just few of your devices, or you're a big enterprise with established ways how to handle it, but anything between is very annoying. Imagine having severals users and instructing everyone to manually install certificates to their devices. That's not good. Also very unwise for those users, because then you would be able to issue certificates for other servers and their devices would trust them.

That's advantage of trusted certificates, all regular systems (Windows, ...) already include many CA certificates (like Let's Encrypt). So if you get LE certificate for your SSTP or other server, client is able to verify that's not fake. And without any manual config on client side. Catch is, it only works with clients where manufacturers handle updates of CA certificates, because they too can change, but not too frequently.

But if you use a client where manufacturer doesn't handle this, it's up to you. For example, RouterOS doesn't include any certificates by default. So a RouterOS client connecting to SSTP server with LE certificate needs LE's root certificate, to be able to verify server's. And it's up to you to keep it updated. It needs to be done only once a few years, but even that's problematic for regular non-technical user.

And if it wasn't bad enough, there's not just CA certificate and server's certificate, there are other intermediate certificates between them. And they too need to be verified, have own validity period, and everything. The right way is for server to send intermediate certificates to client, so that client needs only root and nothing else. The catch is, if you misconfigure this and server sends just its own certificate without intermediates, regular clients like Windows won't probably notice, because they already got necessary intermediate certificates from elsewhere. But RouterOS client with just root certificate will have problem with that.

And it can be even worse, because in order to support some old clients, LE is currently by default providing wrong certificate chain with expired certificate. Some clients ignore that, but some don't. And good luck getting it going if you don't know much about it.

So again, certificates are great. But they work best when someone else does all the required work.

-
(*) With a public CA, there's at least theoretical possibility to bribe someone inside to issue certificate for someone else's server. It's very unlikely and there are countermeasures against that. With your own CA, it's not possible at all. And sure, they could simply beat you up and make you, but the point is that you'd definitely notice it.

Whether you need to upload private key depends on LE client, if it reuses the old one, or creates new one. New key for every certificate is probably default, at least judging by few LE clients I've seen. Even if it stays the same, I don't know if RouterOS would take it from previous certificate. Also don't forget about intermediates, RouterOS server should have them too.

Wireguard rocks every other VPN needing client certificate management up the ying yang sucks

It depends. Wireguard's simplicity is great. If you need it for yourself or just few users, it's perfect. But it's also kind of dumb. Once you need something more dynamic, starting with addresses, adding and removing subnets, or generally some kind of centralized management, you need another layer to handle that. I'm a bit afraid that we can expect war between incompatible standards that will try to solve these things.

It seems to me, that the most capable is still the good old OpenVPN, which can do all kinds of things. Even its use of certificates is not that much annoying, you can have own CA with long validity, and also include everything in one config file, so it's not too bad to manage. Also thanks to same one implementation everywhere, compatibility is very good. Well, except for MikroTik of course, they unfortunatelly had to do their own and not so much compatible thing.


I don't know, all these "everything in cloud", "outsource it to someone else" things, even though they can be convenient for some, and even have some extra added value, I don't think it's the right way. But I won't say that I'm objective and my opinion is the only right one.

@mike6715b: Few things:

- I may be wrong, but I doubt that fetch supports encrypted ftp. And if you really don't have encrypted private key, transferring it over plaintext connection wouldn't be secure at all.
- The script itself is not very reliable, you should first get new certificate, import it, make sure it's ok, and only then replace and delete the old one.

I was already about to apologize to MikroTik for underestimating them, but when I look at your link, it says "SFTP (SSH File Transfer Protocol)", that's completely different thing.