Community discussions

MikroTik App
 
Cartman
Member Candidate
Member Candidate
Topic Author
Posts: 106
Joined: Wed Jul 23, 2008 6:14 pm

Certificate signing

Thu Sep 08, 2022 5:01 pm

Hello world !!!

I have some trouble getting my imported certificates to work.
The CA is shown with KLAT flags, which looks OK for me.
A second certificate comes up with KT flags.

When I try to sign the cert using the ca, it does not work:
/certificate> sign "OVPN Server" name="OVPN_Server" ca=CA
failure: At least one field specifying certificate name must be set!
In my little world name="OVPN_Server" is a specified name.

Funfact:
When name and "the other name" are identical, even MikTik finds
at least one name.
/certificate> sign "OVPN Server" name="OVPN Server" ca=CA
failure: name must be unique!
The is no other certificate named "OVPN Server"

Is there a way to use already signed certificates on a new device?
It was quite hard to get fourty social workers to work via OpenVPN.
Repeating this little war each time a device needs to be replaced
is something i would like to prevent.

TIA

ROS is 6.49.6
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Certificate signing

Thu Sep 08, 2022 11:54 pm

Among the parameters of a certificate in the RouterOS configuration, the name one is just the internal name used to refer to the certificate from elsewhere in the Mikrotik configuration (such as the certificate item in the /interface ovpn-server server configuration). This parameter is not part of the actual contents of the certificate. But the purpose of the certificate is to prove authenticity of some identity, and that's what the simple common-name and more structured (and more recently added) subject-alternative-name fields of the certificate itself are used for. When a client connects to a remote server specified by an fqdn such as my.vpn.server.org, it checks that the subject-alt-name of the certificate received from the server contains a DNS:my.vpn.server.org item. For some clients it is enough if my.vpn.server.org is in the common-name field, some require that it is in the SAN field.

The certification authority certificate doesn't need a CN nor an SAN as you must install it at the device that needs to be able to verify that the certificate presented by a peer has been issued by that certification authority, i.e. you do not use the CA certificate to authenticate the identity of the certification authority itself. That's why you can sign the CA certificate without CN or SAN set. But when signing the server (or client) certificate, at least one of these two fields must be set in order that the signed certificate could be used for its purpose.

You can copy a certificate to a new device, but it is not a recommended way. The very idea of certificate-based security is based on a non-symmetric cryptography - you have a private key and a corresponding public key, what has been encrypted (or signed) by one of them can only be decrypted (or the signature can be checked) using the other one, and you can compute the public one from the private one but not vice versa. So when a peer authenticates itself to a challenging peer using a certificate, it encrypts some random data provided by the challenging peer using the private key, and the challenging peer uses the public key received in the certificate to decrypt them; if the result of the decryption is the original data, it proves that the peer presenting the certificate is its rightful owner, because only the rightful owner has the private key.

So the proper way to create a certificate for a device is to let the device generate the private key and a certififcate signing request, then send the CSR to a CA for signing, and then install the signed certificate back (and link it with the private key). Any other way requires that the private key is transported from the device where it has been created to the device that will use it; if the private key leaks during said transport, the security of the certificate is lost.

Due to this, exporting of the certificate along with the private key is only possible if you protect the private key using a passphrase, but any passphrase a human can remember is much weaker than the private/public key security.

So you can export the certificate from the old device and install it on a new one, but as a minimum you should remove the private key (which, in Mikrotik case, means the whole certificate) from the old device, or destroy the old device to prevent it from being used to connect to your VPN.

If you talk about replacing a broken OpenVPN server, the clients should accept any certificate signed by the CA certificate known to them. So again, in the ideal world, you'd have the CA certificate along with its private key stored somewhere offline and only use it to sign new server certificates. Since you have used the Mikrotik as both the CA and the server, export the CA certificate along with its private key using a good passphrase (such as "some-complex-sentence-you-will-nevertheless-definitely-remember-even-in-10-years-from-now,-preferably-in-an-exotic-language") and store it on some media before the Mikrotik breaks.
 
User avatar
k6ccc
Forum Guru
Forum Guru
Posts: 1490
Joined: Fri May 13, 2016 12:01 am
Location: Glendora, CA, USA (near Los Angeles)
Contact:

Re: Certificate signing

Fri Sep 09, 2022 12:11 am

...using a good passphrase (such as "some-complex-sentence-you-will-nevertheless-definitely-remember-even-in-10-years-from-now,-preferably-in-an-exotic-language") and store it on some media

That's what Password Managers are for...
 
Cartman
Member Candidate
Member Candidate
Topic Author
Posts: 106
Joined: Wed Jul 23, 2008 6:14 pm

Re: Certificate signing  [SOLVED]

Mon Sep 12, 2022 11:06 am

Problem solved...

Like so often the problem was not inside the system,
but sitting in front of it.

During the export/import of the config, somehow one
of the user/pass-entries has been dropped. That was
just the one I used to test the connection.

Nothing has been wrong with the certificates. Signing
was not necessary. I just assumed that there was the
problem.

After turning on the debugging for ovpn on the MT
I got more informative entries telling me the password
was wrong.

Who is online

Users browsing this forum: Amazon [Bot], britgent, rextended, rjuho and 83 guests