Manual

A certificate warning on the router or the VPN

Read which warning it is first: unknown issuer, wrong name and expired are three different problems.

You open the router's web interface over HTTPS and the browser puts a warning in front of it. Or your VPN client will not connect and says something about a certificate that is not trusted. It is tempting to click through, but it pays to read what it says first, because the text names the cause.

What it is not: a certificate warning does not mean the traffic is unencrypted. The encryption works; what fails is proving that the other side is who it claims to be. On a router in your own meter cupboard that is a different risk than on a bank. It is not a firewall problem either: you clearly got through, or there would be no warning.

There are three families of warning. Unknown issuer means your machine does not know the signer. Name does not match means the address you typed is not in the certificate. Expired means a clock is wrong somewhere.

The quick checks, in order

  1. What does the warning say literally? Click the details. A good answer: a code such as ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID or ERR_CERT_DATE_INVALID. Those three point at three different sections below.
  2. Which certificates are on the router? /certificate print detail. A good answer: a CA and a server certificate, both with the T flag (trusted) and K (private key present). Without the K the router cannot sign with it.
  3. Where is the name? In that same output, look at common-name and subject-alt-name. A good answer: the name or address you connect with appears in subject-alt-name. If it is only in common-name, modern browsers do not accept it.
  4. Is the certificate bound to the service? /ip service print detail. A good answer: www-ssl shows certificate=webfig, not none.
  5. Is the time right? /system clock print together with invalid-before from step 2. A good answer: now falls between the start and the end. See The clock is wrong.

The usual causes, most common first

The certificate is self-signed, and that is normal

A router makes its own CA and signs its web certificate with it. Your laptop does not know that CA, so it does not trust it. Nothing is broken. You have two routes: import the router's CA once into the certificate store of your management machines, or use a certificate from a public issuer.

The name in the certificate is not the name you type

You connect to https://192.168.88.1 and the certificate was issued on the router's name, for example office-gw. Those are never the same. On top of that, browsers stopped looking at the common-name field years ago: they want the name or the IP address in subject-alt-name, and otherwise they refuse regardless of trust. This is the warning that does not go away by importing the CA.

The clock was wrong when the certificate was made

A certificate takes its start date from the moment it is signed. Created on a router that has just booted and has not spoken to NTP yet, it carries a start date that means nothing. Removing it and creating it again once the time is right is the only clean fix.

The VPN client does not know the CA

With IKEv2 on certificates, SSTP and OpenVPN the router makes a CA of its own. The client has to trust that CA or it refuses. For IKEv2 a pkcs12 file with the chain in it is exported per client; you have to take that file off the router and install it on the device. For SSTP you install the CA certificate separately on the Windows machine, in the "Trusted Root Certification Authorities" store.

What the configurator does about it

  • In Management access, as soon as you enable HTTPS (www-ssl), the toggle HTTPS: create a self-signed certificate appears, on by default. The script then creates local-ca with a validity of 3650 days, signs it, creates webfig with the router's name as common name, signs that with the CA and binds it to www-ssl and to api-ssl when that is on.
  • Be clear about that certificate: it gets no subject-alt-name, and the common name is the router's identity, not the address you connect to. A browser will therefore warn about it in any case, even after you import the CA. It is there to encrypt the traffic, not to earn a padlock. If you want the padlock, use Let's Encrypt or install a certificate with a SAN in it by hand.
  • Services & tools has the field Let's Encrypt certificate for this hostname. The script opens port 80 from WAN temporarily, runs /certificate enable-ssl-certificate dns-name=..., closes port 80 again and enables www-ssl. The tool warns alongside it that the name has to point at this WAN address and that you need at least RouterOS 7.1.
  • Mind the renewal: that port 80 closes again after the request. RouterOS renews the certificate by itself later, and needs port 80 once more to do it. Put a lasting rule back if you want the renewal to happen on its own, or keep an eye on the expiry date.
  • In VPN, IKEv2 on certificates creates a vpn-ca, a server certificate on the FQDN you enter, and one certificate per client that is exported as pkcs12 with the passphrase you fill in. SSTP and OpenVPN get their own ppp-ca and ppp-server, with a subject-alt-name when the public endpoint is a hostname.
  • What the tool does not do: it does not put certificates on your laptop or phone. Trust on the client side is handwork, on every device separately.

Where the cause lies outside your router

  • The client's clock. A phone or laptop with the wrong date refuses a certificate that is perfectly fine.
  • HSTS in the browser. If a domain ever sent HSTS, you cannot click the warning away. Use another name, or the IP address.

Read on: Certificates, Management access and Remote access VPN.

Want to try it right away? Open the configurator