Manual:System/Certificates: Difference between revisions
| Line 452: | Line 452: | ||
Now on '''client''' router we can add SCEP client: | Now on '''client''' router we can add SCEP client: | ||
<pre> | <pre> | ||
/certificate add-scep template=tpl_1 scep-url="10.5.101.231/scep/test" | /certificate | ||
add common-name=tst-client name=tpl_1 | |||
add-scep template=tpl_1 scep-url="10.5.101.231/scep/test" | |||
</pre> | </pre> | ||
<pre> | <pre> | ||
Revision as of 15:48, 1 April 2016
Applies to RouterOS: v6.12 +
Summary
Sub-menu: /certificate
Package required: security
Standards: RFC 5280, draft-nourse-scep-22
Certificate manager is used to collect all certificates inside router, to manage and create self-signed certificates and to control and set SCEP related configuration.
Note: Starting from v6 certificate validity is shown using local time zone offset. In previous versions it was UTF.
Warning: RSA Key length must be at least 472 bits if certificate is used by SSTP. Shorter keys are considered as security threats.
Starting from v6rc10, CRL will be automatically renewed every hour for certificates which have "trusted=yes" using http protocol (ldap and ftp is currently unsupported). Segmented CRL is also currently unsupported.
RouterOS allows to manage and create self-signed CAs. Implementation was made based on RFC 5280 and all certificates are X.509 v3.
All certificate fingerprints are SHA1. Starting from v6.18 sha256 is used for certificate fingerprints and hashes. All private keys and CA export passphrase are stored encrypted with hardware ID. CA CRL renewal happens at every certificate revocation and after 24hours.
Warning: even if all trust chain is imported, crl may not work in cases when CRL is signed with a different certificate, not the one from trust chain (for example Verisign is doing that)!
Note: Time and date on routers MUST be correct
General Menu
Sub-menu: /certificate
General menu is used to manage certificates, add templates, issue certificates and manage SCEP Clients.
Note: Certificate templates are deleted right after certificate issue or certificate request command is executed
Note: If CA certificate is removed then all issued certificates in chain are also removed
Properties
| Property | Description |
|---|---|
| common-name (string; Default: ) | |
| copy-from (string; Default: ) | |
| country (string; Default: ) | |
| days-valid (integer [0..4294967295]; Default: ) | |
| key-size (1024 | 1536 | 2048 | 4096 | 8192; Default: ) | |
| key-usage (list of [digital-signature | content-commitment | key-encipherment | data-encipherment | key-agreement | key-cert-sign | crl-sign | encipher-only | decipher-only]; Default: ) | Detailed key usage descriptions can be found in RFC 5280 |
| locality (string; Default: ) | |
| name (string; Default: ) | Name of the certificate. Name can be edited. |
| organization (string; Default: ) | |
| state (string; Default: ) | |
| subject-alt-name (string; Default: ) | contact email address |
| trusted (yes | no; Default: ) | If set to yes certificate is included "in trusted certificate chain" |
| unit (string; Default: ) |
Read-only Properties
| Property | Description |
|---|---|
| authority () | |
| ca () | |
| ca-crl-host () | |
| ca-fingerprint () | |
| crl () | |
| dsa (yes | no) | |
| expired (yes | no) | Set to true if certificate is expired |
| fingerprint () | |
| invalid-after (date) | The date after which certificate wil be invalid. |
| invalid-before (date) | The date before which certificate is invalid. |
| issued () | |
| issuer (string) | |
| private-key (yes | no) | |
| req-fingerprint () | |
| revoked () | |
| scep-url (string) | |
| serial-number (string) | |
| smart-card-key (string) | |
| status () | Shows current status of scep client |
Commands
| Command | Description |
|---|---|
| add () | Adds new certificate template. |
| add-scep (ca-identity name on-smart-card scep-url template) | Add scep client. Command takes four parameters:
|
| ca-set-passphrase () | |
| card-reinstall () | |
| card-verify () | |
| create-certificate-request () | Create certificate request from specified template. |
| export-certificate () | Export certificate to file. When export-passphrase is specified, certificate will be exported with encrypted key. |
| import (file-name) | File name of certificate or key to be imported. |
| issued-revoke () | Revoke issued certificate |
| scep-renew () | |
| sign-certificate-request (ca, days-valid, file-name, key-bits) | Generates certificate and key, except that standard parameters are taken from certificate request. Command takes four parameters:
|
| sign (ca, ca-crl-host, ca-on-smart-card, name, template) | Sign certificates. Command takes 5 parameters:
|
SCEP
Sub-menu: /certificate
Standards: draft-nourse-scep-22
Simple Certificate Enrollment protocol (SCEP) was developed based on draft-nourse-scep-22.
The protocol is designed so that any user can request certificate as simple as possible. The protocol allows to issue and revoke certificates.
How SCEP works
Topology: CL ---- RA ---- CA
- CL - client
- RA - registration authority (proxy)
- CA - certification authority (server)
Warning: RA certificate must not contain CA flag
SCEP is using HTTP protocol and base64 encoded GET requests. Most of requests are without authentication and cipher, however important ones can be protected if necessary (ciphered or signed using received public key).
SCEP client in RouterOS will:
- get CA certificate from CA server or RA (if used);
- user should compare fingerprint of the CA certificate or if it comes from the right server;
- generate self-signed certificate with temporary key;
- sends certificate request to the server;
- if server respond with status x, then client keeps requesting until server sends an error or approval.
SCEP server supports issue of one certificate only. RouterOS supports also renew and next-ca options:
- renew - possibility to renew old certificate automatically with the same CA.
- next-ca - possibility to change current CA certificate to the new one. Client polls the server for any changes, if server advertise that next-ca is available, then client may request next CA or wait until CA almost expires and then request next-ca.
RouterOS Server also supports POST' operation, 3DES cipher and SHA1 hashing. If client does not support these features then http GET, DES cipher and MD5 hashing is used.
RouterOS client by default will try to use POST, 3DES and SHA1 if server advertises that.
Server
Sub-menu: /certificate scep-server
OTP
Sub-menu: /certificate scep-server otp
RA
Sub-menu: /certificate scep-server ra
Requests
Sub-menu: /certificate scep-server requests
Configuration Examples
Basic SCEP Example
In this example we will show how to use SCEP to automatically sign certificate for the client in very basic configuration.
First thing we need to do is create CA template on the server and sign it.
/certificate add common-name=ca name=ca-tpl sign ca-tpl name=ca
Now we have valid CA that can be used to issue certificates:
[admin@MikroTik] /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 COM.. SUBJECT-ALT-NAME FIN.. 0 K A T ca ca fb7..
Next step is to create SCEP server:
/certificate scep-server add ca-cert=ca path=/scep/test
Now on client router we can add SCEP client:
/certificate add common-name=tst-client name=tpl_1 add-scep template=tpl_1 scep-url="10.5.101.231/scep/test"
[admin@MikroTik] /certificate> print detail
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, A - authority,
I - issued, R - revoked, E - expired, T - trusted
0 K T name="tpl_1" issuer=CN=tst-client common-name="tst-client"
key-size=2048 days-valid=365 trusted=yes key-usage=key-cert-sign
scep-url=10.5.101.231/scep/test serial-number="1B05992DC13289A9"
fingerprint="a2c0194bf67a12b8902fab45539e157396d2f8fd15f895399da856f64d
6e50c7"
req-fingerprint="e5131662a8c11cfa363c907a49b7f65f9e0e378fc8c8a6d35ae949
3f21fa25be"
ca-fingerprint="fb7b92de75d5e8a90489b4bf9e9ed1808fdcba1e644152cc791f717
cb6b283e2"
invalid-before=apr/01/2016 14:53:34
invalid-after=apr/01/2017 14:53:34
challenge-password="85f5ed5c5b5ea2d336c2"
status="requesting-pending-certificate"
1 A T name="tpl_1_CA" issuer=CN=ca common-name="ca" key-size=2048
days-valid=365 trusted=yes
key-usage=digital-signature,key-encipherment,data-encipherment,key-
cert-sign,crl-sign,tls-server,tls-client
serial-number="130D81F32DBD8BF2"
fingerprint="fb7b92de75d5e8a90489b4bf9e9ed1808fdcba1e644152cc791f717cb6
b283e2"
invalid-before=apr/01/2016 15:25:14
invalid-after=apr/01/2017 15:25:14
As you can see SCEP client status shows "requesting-pending-certificate", which means that we manually must grant certificate on the server:
[admin@MikroTik] /certificate scep-server requests> print # AUTHORITY STATUS COMMON-NAME CREATED 0 ca pending tst-client apr/01/2016 12:29:55 [admin@MikroTik] /certificate scep-server requests> grant 0 [admin@MikroTik] /certificate scep-server requests> print # AUTHORITY STATUS COMMON-NAME CREATED 0 ca granted tst-client apr/01/2016 12:29:55
After status change to "granted", you will see new issued certificate on the server:
[admin@MikroTik] /certificate> print detail
1 I name="issued_2" common-name="tst-client" key-size=2048 days-valid=1
trusted=no key-usage=digital-signature,key-encipherment,data-encipherment,
key-cert-sign,crl-sign,tls-server,tls-client
ca=ca serial-number="66071C63F77EB672"
fingerprint="89b0000ab75375e887b80ca45e829dfb6e683f6429069242c83063798ad8698
1"
invalid-before=apr/01/2016 15:31:58 invalid-after=apr/02/2016 15:31:58
And a working certificate on the client:
[admin@MikroTik] /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 COM.. SUBJECT-ALT-NAME FIN.. 0 K T tpl_1 tst.. a2c.. 1 A T tpl_1_CA ca fb7..
[ Top | Back to Content ]