Certificate import / creation, clarification sought?

RouterOS General
1

Hi,

I’m looking to set up a VPN (IKE2/IPSEC) server on my RB750Gr3 which now has the latest software (7.15.2) so I can connect to this when away from home using someone else’s network. I’ve done all of this apart from the certificate part as it always confuses me, so would like to run the following past you as I’m using XCA to create these.

Having done some research it seems best practice to create a CA rather than just some self signed certificates so I’ve gone for the approach of creating my own CA and intermediate CA. I’m mainly confused over which bits of this need importing into my router and what should show up as the status identifiers next to each certificate. I’ve already done the Lets Encrypt process to enable a certificate for logging in to the router and that has ‘KT’ next to that certificate.

Cert creation steps taken:

  1. CA private key
  2. CA Root Cert (Self Signed)
  3. ICA private key
  4. ICA Cert (Signed by CA Root Cert)
  5. TLS Server private key
  6. TLS Server Cert (Signed by ICA Cert)
  7. TLS Client private key
  8. TLS Client Cert (Signed by ICA Cert)

Do I only need to import 2,4,5,6 & 8 and tick trusted for them all?

What status category should appear next to these, presuming CRL is set up correctly too?


The second part I need some clarification on please is around CRL:

Should all of the above certs be referencing a CRL or would the TLS certs get their awareness of a CRL from the CA that signed them?

Should the CA & ICA have their own distinct CRL, with the ICA referring to the CA generated one, and the TLS certs referring to the ICA generated one?

Thanks in advance for any clarification you can provide.

2

As for best practice, some client software simply does not accept self-signed certificates. On the other hand, to use an intermediate CA is more or less a redundant burden unless you have good reasons to do so.

As for what to import:

  • each entity that wants to prove its identity to a partner needs to have its own certificate and the private key to it. In the best possible world, you would not even import the private key - instead, you would generate a Certificate Signing Request (which, on Mikrotik, also generates the private key), deliver the CSR to the CA for getting signed = converted into a signed certificate, and then you would import first the signed certificate received back from the CA and next the locally stored private key. So the private key would never be seen anywhere else than at the entity using it.
  • each entity that needs to verify identity of a partner who presents its own certificate to prove it must have in its list of trusted CAs at least the root CA of the chain of trust of the certificate being presented
  • regarding intermediate certificates, there are two options that may coexist. The party presenting the certificate may send not only its own certificate but also all the certificates in its chain of trust as part of establishing the secure connection, and the party inspecting the certificate may have the complete chain of trust imported to its certificate store; technically and on Mikrotik in particular, either way is sufficient, but it is recommended to follow the first one as some implementations require it. It means that also the party presenting its certificate must have the certificates from the whole chain of trust in its store.

In your case, the responder (the Mikrotik) uses the Let’s Encrypt certificate to prove its identity whereas the initiator (supposedly your PC) uses your own home-brewn chain of trust. So the PC needs to have the Let’s Encrypts chain of trust (currently, ISRG Root X1 and Let’s Encrypt R10 if the certificate has been generated in July), which should be ensured by the Windows/iOS/whatever update service so no need to import them manually, and its own certificate and the private key for it; the Mikrotik needs to have the complete chain of trust (root CA + intermediate CA in your case) as I don’t know whether the VPN client on your laptop can add the other certificates to the message if it has them in its store, never tried that so far.

On Windows in particular, the own certificate must be imported as a machine one rather than a user one, and unless something has changed recently, there is no way to import it without decryption of the private key and ask for the decryption passphrase at every connection, which means a stolen laptop can connect. There is also a possibility to use username&password rather than a certificate to authenticate the initiator to the responder if you can run a RADIUS server on the responder side - in ROS 7, User Manager can be used for this purpose. It did fit to a 15-year old RB411 so it may fit to hEX Gr3 too, but I haven’t checked that.

Plus, if you connect several PCs, you can use their respective certificates not only for authentication but also for identification on the responder side; to allow that, the responder must have them in its store and let the /ip ipsec identity items refer to them. Of course, the responder should not know the private keys of the initiators’ certificates.

As for CRL, I think it would be an overkill for the use case you’ve described. It is easier to keep an /ip ipsec identity row with the compromised certificate and let it connect nowhere than to set up the CRL infrastructure. Anyway, the hierarchy in the chain of trust is such that the root CA has no knowledge about certificates signed by the intermediate CAs, so it sounds logical that it also doesn’t have the responsibility for their revocation, hence the issuing (signing) CA must be responsible for maintaining a CRL for the certificates it has issued (signed). But I may be wrong here.

3

Hi Sindy,

Thanks for the detailed reply, I may have confused you a bit I think with my mentioning of Lets Encrypt. The LE certificate was generated automatically by my MT router and is only used AFAIK to enable the ‘www-ssl’ service, in ‘IP/Services’. I only mentioned this LE certificate because it’s my example of one done correctly as far as the server cert is concerned, the CA aspect differs because LE is a real CA compared to my own fake CA scenario. So what I was trying to explain was the LE cert has two category letters next to it in the list of certs. ‘KT’, indicating that the private key is present and the cert is trusted. I’m assuming my own generated TLS Server private key & Cert (items 5&6 from my numbered list in the OP) need to be imported to MT and would show the same status categories as the LE one, unless I have configured CRL in mine which may show an additional category status character.

Then I went on to ask, out of the private keys and certs that I’ve created offline (not on the MT router), (8 items in the numbered list in the OP), which of these should be imported to the MT router?

I think the part you mention about CSR is not relevant to my use case. I’m not sending any certs to a CA via a CSR, I’m creating my own indirectly via OpenSSL using the XCA application. With this application, it generates private keys, self signed CA root certs, ICA’s, end entity certs, CRL’s, even vCalendar exports. This information is all password protected in the integrated database embedded in the application which resides on a protected laptop inside my LAN. So the private keys are generated inside my LAN and aren’t seen by anyone. Unless the private keys for my CA, ICA and client certs are required on the MT router then this won’t ever have even seen them, so surely more secure than generating all of this on the MT router itself.

Moving on to your last two bullet points regarding the CA’s and the chain of trust. Does it make any difference if the CA and ICA are imported individually to the MT router or a client device or should they be exported in a chain file, such as a PEM chain file for the CA’s without the private keys?

I’m not using the Lets Encrypt provided cert for the VPN set up. I have the DNS for my own domain set up with a sub domain, vpn.mydomain.tld and an A record pointing to my fixed IP provided by my ISP, (WAN IP). Therefore I used the ICA to sign my own XCA home made end entity cert. for TLS Server Auth. with a common name and subject alt. name matching vpn.mydomain.tld. I’m assuming this server cert should be imported to the MT router along with its private key as it is a similar cert. to the one that exists from Lets Encrypt, except that refers to mydomain.tld rather than a sub domain of it. Can my server cert that was made in XCA be exported either as a separate PEM .crt file along with a separate export of the private key (unencryted key .pem file or encrypted key PKCS #8?) or the cert. and the private key as one encrypted PKCS #12 .pfx file?

Lets say I’m ignoring the RADIUS server option at this time, how should I export the client certificates for importing to client devices such as Windows? Should this be an encrypted PKCS #12 chain file containing the complete cert. chain and the private key? I concur on importing into the machine store rather than the personal store on Windows. The Windows 10 inbuilt VPN connection process only requires the server URL, VPN type: IKEv2, Type of sign-in info: General authentication method. In the corresponding WAN Miniport network adapter settings, authentication is set to ‘Use machine certificates’. I don’t think it matters too much if it doesn’t ask for a password as the laptop is protected well anyway including the BIOS.

I am planning on connecting a few devices, Windows and Android based so each of these will have a client cert. that is also stored on the MT router and is indeed referred to in /ip sec identity. Thanks, I acknowledge your point then that the private keys for the client certs. should not be on the MT router.


As for the CRL solution, at the moment my understanding is as follows:

The MT complains if referring to the CRL Distribution Points with a https URI, as it doesn’t like that protocol according to the MT ROS log. It also complains if the CRL has been produced in .der format.

CA Root, has CRL Distribution Point: critical, URI:http://crl.mydomain.tld/ca.crl
ICA, has CRL Distribution Point: critical, URI:http://crl.mydomain.tld/ca.crl

but the end entity certs (servers and clients) have a CRL Distribution Point, pointing to a CRL generated by the ICA that signed it, e.g., CRL Distribution Point: critical, URI:http://crl.mydomain.tld/ica.crl

I may have different ICA’s for home lab use to create a logical separation of purpose to these as I believe it makes cert. management more logical, so I may also adopt: CRL Distribution Point: critical, URI:http://crl.mydomain.tld/ica{-purpose}.crl that ties in with the naming convention of the related ICA.

This doesn’t however fit with the MT help docs. here https://help.mikrotik.com/docs/display/ROS/Certificates. That suggests making 3 self signed certs which are all CA’s and only the ServerCA one has the CRL flag shown next to it. I don’t feel that is a good example as why would you produce self signed CA’s and not sign a server or client end entity cert. with only one self signed CA cert or ICA? :unamused:

For reference, here are the links for XCA for anyone wondering what this is:
https://www.hohnstaedt.de/xca/
https://www.hohnstaedt.de/xca/index.php/documentation/stepbystep

The above documentation suggests the CRL info being added to both a CA and a CA signed host cert. That’s what leads me to think they should all have the CRL info added but referencing a distinct file location that relates to the CA that signed it.

Appreciate if you or whomever can clarify the points I’ve raised please…

4

All certificates, as you plan to use the client ones not only to authenticate them but also to identify them. Only Mikrotik’s own private key.


Indeed, it’s just the most secure way and I did not know that XCA was an application you run in your home lab - the description of the use case was “one router at home to which I connect while travelling”. That did not sound like a home lab with multiple ICAs as you describe now :smiley:


Indeed, but it’s not the case any more if the MT router (or anything else) is not generating them (including the private keys) but only signing them. Anyway, it does not make any difference in your case as you do not send the private keys outside your LAN.


I don’t know any device/OS that would care whether some certifcates came in a single common file or in separate ones; in either case they store them separately in the certificate stores. Exporting multiple certificates into a single file only makes the workflow more comfortable, as in “less clicking is required”.


As far as I know, Mikrotik would not import a private key that is not protected by a passphrase, and it only supports PEM (base64) format or PKCS#12 (binary) one. If you had in mind exporting from the Mikrotik (I don’t think so so just for completeness), if you choose type=pem, you’ll get two files, .crt with the certificate being exported itself and .key with the private key to that certificate. If you choose type=pkcs12, it will export the certificate it was asked to export, its private key, and its complete chain of trust (if available) into a single file. If you do not provide the passphrase, it will omit exporting the private key in either format.


That is indeed the best way - the least amount of clicking is required.


Regarding CRL, as already said I am not an expert, so I let someone else respond.


I share your excitement about this example, it is unusually bad.

5

Thanks Sindy,

Has worked out fine as far as the certs are concerned. Shall try and test out the CRL config. later in the week.