BOUNTY for help offered - hardware upgrade - certificate export/import issue

I’m upgrading a older MikroTik unit to a new hardware… I managed to get the config over and works great… but I realized my openVPN server config didn’t work!

I assume now that the certificates are the root cause. I also figured out I can export/import them BUT thats not working… I missing key’s I guess because after import they flag show they are missing…

Offering $100 via PayPal for the first person who can provide me command line export/import step by step to get this done…

Once I received the step by step and was able to export/import my certificates and also can use this for backups I will gladly PayPal you $100

Any takers?

Any advise?
-max

You have to export the certificates with a passphrase, otherwise the private key won’t be exported.

Figured that out…but it doesn’t work…

1.) The imported certificates miss the “I” flag I assume “issued”… no idea if that a problem but

2.) When I try to establish the OVPN I get some error about unknown CA?

Something is wrong… and its beyond my knowledge hence the bounty…

:-/

I don’t work with certificates in RouterOS much, I mostly import existing ones created elsewhere (that’s my preventive excuse :slight_smile:). But it seems to work fine.

On first router, I create new certificates like this (based on manual):

/certificate
add name=ca-template common-name=myCa key-usage=key-cert-sign,crl-sign
add name=server-template common-name=server.example.net
add name=client1-template common-name=client1
sign ca-template name=myCa
sign server-template ca=myCa name=server
sign client1-template ca=myCa name=client1
set server trusted=yes

Then I export required certificates for client (they go in config file):

/certificate
export-certificate myCa
export-certificate client1 export-passphrase=xxxxxxxx

I configure OpenVPN on router with “server” certificate, and client can connect.

To move certificates to another router, I first export them:

/certificate
export-certificate myCa export-passphrase=xxxxxxxx
export-certificate server export-passphrase=xxxxxxxx

Then on second router:

/certificate
import file-name=cert_export_myCa.crt passphrase="xxxxxxxx"
import file-name=cert_export_myCa.key passphrase="xxxxxxxx"
import file-name=cert_export_server.crt passphrase="xxxxxxxx"
import file-name=cert_export_server.key passphrase="xxxxxxxx"

After setting certificate for OpenVPN server and changing server.example.net to point to new router, client can connect again, without any changes required.

Interestingly, I have no “I” flag at all (this is from original router):

/certificate print
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
 #         NAME                                         COMMON-NAME                                       SUBJECT-ALT-NAME
 0 K  A  T myCa                                         myCa
 1 K  A  T server                                       server.example.net
 2 K  A    client1                                      client1

Update: To get “I” flag, it’s necessary to specify key-usage:

/certificate
add name=server-template common-name=server.example.net key-usage=tls-server,digital-signature,key-agreement,key-encipherment
add name=client1-template common-name=client1 key-usage=tls-client,digital-signature,key-agreement

This looks like bug to me, because even without it, certificate is still issued by CA on router (and it gets some implicit key usage too).

The “I” flag is lost when certificate is imported to another router. But client still connects without any complaints.

@Sob, I’m afraid you haven’t chosen the best testing method, as OpenVPN client wasn’t checking the server certificate until the 6.45beta54 (where you have to explicitly activate that check).

Actually, I tested RouterOS only as OpenVPN server (that’s how I understood OP), client was standard Windows one and it does verify server certificate. So the result should be correct, but I should have written what exactly I was doing (I sort of did, I mentioned “config file” for client, but I agree that wasn’t enough).