I’m facing a problem with certificate signing on RouterOS 7.16.
I have CLIENT-tpl template certificate with defined days valid attribute (e.g. 365days)
I have valid CA certificate, not expired.
After signing process was done, certificate was expired with attribute values:
Invalid Before: Jan/01/1970 02:00:00
Invalid After: Jan/01/1970 02:00:00
My clock is synchronized with NTP server and time is correct.
Recently, I was generating my certificates exactly same way with no issues.
Am I facing a bug?
/certificate
add name=CA-Template common-name=CAtemp key-usage=key-cert-sign,crl-sign
add name=Server common-name=server
add name=Client common-name=client
sign Server name=ServerCA (yes that makes no sense here in practice, testing :) )
sign Client ca=ServerCA name=testtest
print
Flags: K - PRIVATE-KEY; A - AUTHORITY; T - TRUSTED
Columns: NAME, COMMON-NAME, SKID
# NAME COMMON-NAME SKID
0 KAT test test 8edeb8371f2d99b45bc78499776159852bd1c81a
1 KA test2 test2 23220e94100e7740f7f1283965030f58fa14be0b
2 CA-Template CAtemp
3 KAT ServerCA server 66505d111a6b5e96bdf928ca3b52884b438812de
4 KA testtest client ce977beb05b8b2782a970e1a8004462b68ee6bfa
It indeed looks like a bug to me. I am also signing the client certificates using a CA on Mikrotik, but using the “correct” way where the private key is generated on the client itself along with a certificate signing request, the request alone is then transferred to the CA Mikrotik and signed there using certificate sign-certificate-request, and the signed certificate gets imported back on the client first and the locally generated key next, and I haven’t experienced such a behaviour yesterday when signing a certificate request using 7.16.1. So if you can, try this way. If your client does not allow to generate certificate signing requests (many don’t), you can still use certificate create-certificate-request on the CA Mikrotik itself instead. So the private key will be generated there, and much like when you directly sign the template, you’ll be able to import the key and the signed certificate to the client (or maybe you’ll have to import the key locally and then export certificate+key in pkcs12 format if that’s the only format the client can import).
In any case, it would be nice if you could create a supout.rif file right after the certificate with wrong dates gets generated, and open a support ticket with Mikrotik. Without that, the bug can never be fixed.
Same story here, upgraded my Mikrotik to 7.16.2 and a freshly generated certificate is invalid.
/certificate print detail shows:
invalid-before=1970-01-01 02:00:00
invalid-after=1970-01-01 02:00:00
Currently, I can’t create a VPN connection for our new colleague. I would appreciate any help or workaround. Thanks
Truth be told, I’m not skilled in certificates. I’m following a setup for an OpenVPN, which creates the certificate (key) directly on the Mikrotik. However, if this doesn’t get fixed soon I might need to learn a new way (workaround).
EDIT: Reported using Mikrotik service desk (SUP-173239) with a link to this thread.
