[admin@MikroTik] /certificate> export-certificate CA…
failure: Templates are not exportable!
An error occurs when exporting CA certificates.
How to defeat this error?
6.48.3 RB750
No one was engaged in exporting?
Can you do it in the GUI Winbox interface?
You need a советник!!!
The soluction is in the picture, whiy you do not read what is wroted inside?
the templates are not certificates
and you can not export one certificate than is not a certificate…
thanks.
But then the question is, how to create a certificate for export?
I'm setting up an IPsec VPN.
A template is not a complete certificate, so there is, strictly speaking, nothing to export.
The whole workflow should be the following:
- the future user of the certificate creates a “certificate signing request” (in RouterOS, it can only be created from a template), which causes also a creation of a private&public key pair; the public key is part of the certificate signing request contents (and will be part of the certificate), the private key is not. In RouterOS, you must specify a passphrase so that you could import the private key in a later step.
- the future user sends the file with the certificate signing request to a Certification Authority (CA)
- the certification authority signs the file with its own certificate. If RouterOS is used as the CA, the command is /certificate sign-certificate-request.
- the CA exports the signed certificate into a file (no passphrase is necessary although RouterOS asks for one) and sends the file to the certificate user
- the certificate user imports the certificate and links it with the private key; whilst this is automatic on some operating system, in RouterOS, you have to import the file with the private key that has been generated when generating the CSR after importing the certificate (and you need the passphrase mentioned above). You cannot import the key in advance.
If done this way, the private key is generated on the device where it will be used and never leaves it, so it is the most secure method. The CSR and the signed certificate can be sent via plaintext channels as they are useless without the private key.
The simplified workflow is that you create the certificate template at the device acting as a CA, and sign it there. The command is /certificate sign in this case, and it first generates a private&public key pair and certificate signing request for the certificatelocally, and then signs it with its own certificate. So the private keys of certificates generated this way remain available at the CA. To deliver the certificate to some other device, you have to export it, and if the device will use it to authentify itself, you have to export also the private key. If you enter a passphrase, both the certificate and the private key will be exported; of you leave it empty, only the certificate will be exported. The latter is useful when you send the certificate to a device that will use it to identify a remote user, not to authentify itself.
If you use type=pkcs12 during export, the resulting file will contain the certificate itself and all the certificates on the way to the signing CA included, and also the private key if passphrase has been specified and if the private key was available. If you use type=pem, one file will contain only the certificate itself, and another file will contain the private key (of course also only if passphrase has been specified and if the private key was available).
Remember that for IPsec (and other purposes), you need your own certificate with a private key to authentify to the remote party, and you need the certificate of the CA that has signed the remote party’s certificate to authentify the remote party to you. You may need the remote party’s certificate itself (but you don’t need its private key) if you want to use it as an index to the /ip ipsec identity table.
A root certification authority signs its own certificate itself, so you also use /certificate sign, but don’t specify any value of the ca parameter.
Make sure that you set the correct key-usage values when creating the templates. They are different for the CA and for the IPsec initiator and/or responder.