Manual:Create Certificates: Difference between revisions

From MikroTik Wiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__TOC__
==Generate certificates on RouterOS==
RouterOS version 6 allows to create, store and manage certificates in certificate store. Following example demonstrates how to easily manage certificates in RouterOS:
'''Make certificate templates'''
<pre>
/certificate
add name=ca-template common-name=myCa key-usage=key-cert-sign,crl-sign
add name=server-template common-name=server
add name=client1-template common-name=client1
add name=client2-template common-name=client2
</pre>
'''Sign certificates and add CRL url.'''
We will use IP address of the server as CRL URL.
<pre>
/certificate
sign ca-template ca-crl-host=10.5.101.16 name=myCa
sign server-template ca=myCa name=server
sign client1-template ca=myCa name=client1
sign client2-template ca=myCa name=client2
</pre>
{{ Note | If signing certificates on mipsbe cpu based devices(RB7xx,RB2011,RB9xx) then this process might take a while depending on key-size of specific certificate. With values 4k and higher, it might take a substantial time to sign a certificate.}}
If certificate does not have '''T''' flag then you need to set it as trusted before using it:
<pre>
/certificate
set myCa trusted=yes
set server trusted=yes
</pre>
'''Export client certificates''' with keys and CA certificate:
<pre>
/certificate export-certificate myCa
/certificate export-certificate client1 export-passphrase=xxxxxxxx
/certificate export-certificate client2 export-passphrase=xxxxxxxx
</pre>
Now these exported files can be imported on client machines.
If everything went well you should have something like this:
<pre>
[admin@pe0] /certificate> print
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key,
A - authority, I - issued, R - revoked, E - expired, T - trusted
#        NAME              COMMON-NAME              FINGERPRINT             
0 K L A T myCa              myCa                      7fa636e6576495fe78f1a4...
1 K  I T server            server                    cf0650a291bf4685f2fbd3...
2 K  I  client1            client1                  26233de30e89b203b946ab...
3 K  I  client2            client2                  cf172b62201befaf8d8966...
</pre>
{{ Note | Templates are automatically removed after signing certificate}}
==Generate certificates with OpenSSL==
Following is a step-by-step guide to creating your own CA (Certificate Authority) with openssl on Linux.
Following is a step-by-step guide to creating your own CA (Certificate Authority) with openssl on Linux.


==Generate certificates==


{{Note | Starting from v5.15 RouterOS supports '''pkcs8''' key format. If you are using older versions, to import keys in pkcs8 format run command: <br />
{{Note | Starting from v5.15 RouterOS supports '''pkcs8''' key format. If you are using older versions, to import keys in pkcs8 format run command: <br />
Line 16: Line 77:
During the process you will have to fill few entries (Common Name (CN), Organization, State or province .. etc).
During the process you will have to fill few entries (Common Name (CN), Organization, State or province .. etc).
Created CA certificate/key pair will be valid for 10 years (3650 days).
Created CA certificate/key pair will be valid for 10 years (3650 days).
{{Warning | If certificates are generated without key usage, you need to edit openssl.cnf file and specify what key usage to use, or create a new config file and use -config option while generating certificate.}}


<li> Now create private-key/certificate pair for the server
<li> Now create private-key/certificate pair for the server
Line 26: Line 90:
</pre>
</pre>


{{Warning | Key length must be at least 512 bits. Shorter keys are considered security threats.}}
{{Warning | RSA Key length must be at least 472 bits if certificate is used by [[M:Interface/SSTP | SSTP]]. Shorter keys are considered as security threats.}}


And again during the process you will have to fill some entries. When filling CN remember that it must not match on CA and server certificate otherwise later naming collision will occur.
And again during the process you will have to fill some entries. When filling CN remember that it must not match on CA and server certificate otherwise later naming collision will occur.
{{ Note |  Common Name (CN) in server certificate should match the the IP address of your server otherwise you will get <b>"domain mismatch"</b> message and for example Windows [[Manual:Interface/SSTP | SSTP]] client will not be able to connect to the server. If clients are only Windows machines then CN can be a DNS name, too.}}
{{ Note |  Common Name (CN) in server certificate should match the the IP address of your server otherwise you will get <b>"domain mismatch"</b> message and for example Windows [[Manual:Interface/SSTP | SSTP]] client will not be able to connect to the server. If clients are only Windows machines then CN can be a DNS name, too.}}


{{ Note | If you are using "My ID user FQDN" in [[M:IP/IPsec | IpSec]] config then "subjectaltname" extension should be set on certificate, and must match the value set on remote peers "My ID user FQDN".}}




Line 70: Line 135:
</pre>
</pre>


If everything is imported properly then certificate should show up with <b>KR</b> flag.
If everything is imported properly then certificate should show up with <b>KT</b> flag.
<pre>
[admin@test_host] /certificate> print
Flags: K - decrypted-private-key, Q - private-key, R - rsa, D - dsa
0 KR name="cert1" subject=C=LV,ST=RI,L=Riga,O=MT,CN=server,emailAddress=xxx@mt.lv
      issuer=C=LV,ST=RI,L=Riga,O=MT,CN=MT CA,emailAddress=xxx@mt.lv serial-number="01"
      email=xxx@mt.lv invalid-before=jun/25/2008 07:24:33
      invalid-after=jun/23/2018 07:24:33 ca=yes
 
</pre>


{{ Note | If you want to use server certificates for OVPN or SSTP and use client certificate verification, then CA certificate must be imported, too. }}
{{ Note | If you want to use server certificates for OVPN or SSTP and use client certificate verification, then CA certificate must be imported, too. }}

Latest revision as of 07:50, 24 May 2021


Generate certificates on RouterOS

RouterOS version 6 allows to create, store and manage certificates in certificate store. Following example demonstrates how to easily manage certificates in RouterOS:

Make certificate templates

/certificate
add name=ca-template common-name=myCa key-usage=key-cert-sign,crl-sign
add name=server-template common-name=server
add name=client1-template common-name=client1
add name=client2-template common-name=client2

Sign certificates and add CRL url. We will use IP address of the server as CRL URL.

/certificate 
sign ca-template ca-crl-host=10.5.101.16 name=myCa
sign server-template ca=myCa name=server
sign client1-template ca=myCa name=client1
sign client2-template ca=myCa name=client2

Note: If signing certificates on mipsbe cpu based devices(RB7xx,RB2011,RB9xx) then this process might take a while depending on key-size of specific certificate. With values 4k and higher, it might take a substantial time to sign a certificate.


If certificate does not have T flag then you need to set it as trusted before using it:

/certificate
set myCa trusted=yes
set server trusted=yes

Export client certificates with keys and CA certificate:

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

Now these exported files can be imported on client machines.

If everything went well you should have something like this:

[admin@pe0] /certificate> print 
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, 
A - authority, I - issued, R - revoked, E - expired, T - trusted 
 #         NAME               COMMON-NAME               FINGERPRINT              
 0 K L A T myCa               myCa                      7fa636e6576495fe78f1a4...
 1 K   I T server             server                    cf0650a291bf4685f2fbd3...
 2 K   I   client1            client1                   26233de30e89b203b946ab...
 3 K   I   client2            client2                   cf172b62201befaf8d8966...

Note: Templates are automatically removed after signing certificate


Generate certificates with OpenSSL

Following is a step-by-step guide to creating your own CA (Certificate Authority) with openssl on Linux.


Note: Starting from v5.15 RouterOS supports pkcs8 key format. If you are using older versions, to import keys in pkcs8 format run command:
openssl rsa -in myKey.key -text and write key output to new file. Upload new file to RouterOS and import


  • First step is to build the CA private key and CA certificate pair.
    openssl genrsa -des3 -out ca.key 4096
    openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
    

    During the process you will have to fill few entries (Common Name (CN), Organization, State or province .. etc). Created CA certificate/key pair will be valid for 10 years (3650 days).

    Warning: If certificates are generated without key usage, you need to edit openssl.cnf file and specify what key usage to use, or create a new config file and use -config option while generating certificate.



  • Now create private-key/certificate pair for the server
    openssl genrsa -des3 -out server.key 4096
    openssl req -new -key server.key -out server.csr
    
    openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
    

    Warning: RSA Key length must be at least 472 bits if certificate is used by SSTP. Shorter keys are considered as security threats.


    And again during the process you will have to fill some entries. When filling CN remember that it must not match on CA and server certificate otherwise later naming collision will occur.

    Note: Common Name (CN) in server certificate should match the the IP address of your server otherwise you will get "domain mismatch" message and for example Windows SSTP client will not be able to connect to the server. If clients are only Windows machines then CN can be a DNS name, too.


    Note: If you are using "My ID user FQDN" in IpSec config then "subjectaltname" extension should be set on certificate, and must match the value set on remote peers "My ID user FQDN".



  • Client key/certificate pair creation steps are very similar to server. Remember to Specify unique CN.
    openssl genrsa -des3 -out client.key 4096
    openssl req -new -key client.key -out client.csr
    
    openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
    

To examine certificate run following command:

openssl x509 -noout -text -in server.crt -purpose

Import certificates

To import newly created certificates to your router, first you have to upload server.crt and server.key files to the router via FTP. Now go to /certificate submenu and run following commands:

[admin@test_host] /certificate> import file-name=server.crt
passphrase: 
     certificates-imported: 1
     private-keys-imported: 0
            files-imported: 1
       decryption-failures: 0
  keys-with-no-certificate: 0
[admin@test_host] /certificate> import file-name=server.key 
passphrase: 
     certificates-imported: 0
     private-keys-imported: 1
            files-imported: 1
       decryption-failures: 0
  keys-with-no-certificate: 0

If everything is imported properly then certificate should show up with KT flag.

Note: If you want to use server certificates for OVPN or SSTP and use client certificate verification, then CA certificate must be imported, too.


[ Top | Back to Content ]