A certificate does two things at once, and that is why the subject is confusing. It encrypts the connection, and it proves who you are talking to. A self-signed certificate does the first just as well as an expensive one. It does not do the second.
What the tool creates
The configurator creates certificates in three places, and all three do it on the router itself. Nothing goes to a server, ours included: the tool runs in your browser.
WebFig over HTTPS
If you enable the HTTPS service in Management access, HTTPS: create a self-signed certificate is on by default. The script then creates a CA called local-ca and a server certificate webfig, signs that with the CA, and binds it to www-ssl. If API-SSL is on as well, it gets the same certificate. Both are valid for ten years, because a management interface that quietly stops after a year is worse than a long lifetime.
The common name is the identity you entered under System. That is not a hostname your browser knows, so you get a warning. More on that below.
IKEv2
In VPN you can set IKEv2 to use certificates. The script then creates vpn-ca, a server certificate vpn-server with the FQDN you fill in as both common name and subject alternative name, and a certificate vpn-<name> per client. Those client certificates are exported straight away as a .p12 file with the password you set. The CA is inside that file, so the client needs nothing else.
After pasting, those files sit on the router. Fetch them with WinBox under Files, or look first with:
/file printThose .p12 files contain the client's private key. Take them off the router once you have them instead of leaving them there.
The FQDN is not cosmetic here. iOS and Windows check the server name in the certificate against the name you connect to. If they do not match the client refuses, and the error message rarely says what is wrong.
SSTP and OpenVPN
Pick SSTP or OpenVPN and the script creates ppp-ca and ppp-server. The common name becomes the public address or hostname you filled in under VPN; if that is a hostname it is added as a subject alternative name too. Leave it empty and it says router, and every client will complain about the name.
Let's Encrypt
In Services and tools there is one field: Let's Encrypt certificate for this hostname. Fill in a name and the script does this:
- a temporary firewall rule allowing TCP 80 from WAN, at the top of the input chain, with the comment
acme-http01; /certificate enable-ssl-certificate dns-name=…, the RouterOS command that requests the certificate;- removing that firewall rule again;
- enabling
www-ssl.
Two conditions, and the tool states them as well. The name has to point at this router's WAN address, and port 80 has to be genuinely reachable from the internet during the request. Behind CGNAT, or behind a modem that is not in bridge mode, the challenge never arrives and the request fails. See Reaching a changing address.
What happens afterwards is RouterOS's work: it binds the certificate to www-ssl itself and renews it itself. You do not have to set anything up for that. Do check once after a few months that it really happens:
/certificate print detailNote that the field asks for a name reachable from the internet. For a router that only lives inside your own network, Let's Encrypt is not the answer; there you are left with the self-signed certificate, or a CA of your own that you install on your devices.
What the browser warning means
Open HTTPS to a router with a self-signed certificate and your browser says something like "your connection is not private". That is true and misleading at the same time.
What is going on: your browser does not know the CA that signed this certificate, so it cannot verify that this really is your router. If someone were sitting between you and the router, you would not be able to tell from this.
What is not going on: the connection is not unencrypted. The traffic is encrypted exactly as it would be with a certificate from a known CA. Someone listening on the network does not see a password.
In practice that means: on a network you manage, reaching a device at a fixed address, the warning is acceptable. Click it away while you are on a network you do not trust and you are throwing something away. And once you are used to clicking it away, you will click it away on the day something actually is wrong.
To get rid of it there are two routes. Let's Encrypt for a router with a public name, or installing your own CA on your management laptops. The tool does not know that second one: there is no field to import an existing certificate or your own CA, and no CRL is maintained. If you want that, do it by hand on the router with /certificate import.
Checking and tidying up
/certificate printPer certificate you see the flags: K means the private key is present, T that it is trusted, A that it was signed by a CA. A server certificate without K can do nothing. With print detail you see the validity dates.
The lifetimes the tool uses: ten years for the CAs and the WebFig certificate, three years for the VPN server and client certificates. When one expires you create a new certificate and sign it with the same CA; clients then have nothing to reinstall, because the CA they trust has not changed. When the CA itself expires, the whole sequence starts again.
Read on: Management access for the HTTPS switch, Remote access VPN for IKEv2 and the client files, and Reaching a changing address for the name you need.