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.