Key Size with add-acme?

RouterOS General
1

Hello,

How does one set the key-size and other parameters like key-type when using the add-acme command?

It defaults to RSA and 2048 but would really like to use 8192 or at least 4096 bit certificates..

set 0 key-size=8192

before the certificate is issued, gives the error failure: changing acme certs is not supported.

Adding key-size=8192 to the end of the add-acme command has the expected result of bad parameter key-size

I feel that part of creating a "New Certificate" should be adding or enabling acme and the acme directory URL but I can't find it, Create Cert. Request would also seem logical.

Am I missing something obvious?

2

It can't be changed. The root certificate is only 2048.

The certificate has to be less than or equal to the root ca key size.

3

100% false.

4

If the Root CA private key is only 2048! It can not gerenate a key size greater than 2048!

Root CA signing the cert will have a key size mismatch.

An encryption key of 4096 can generate a key size of 4096 or less, say 3072.

And if you could it's wrong.

If you create a self signed certificate with a key size of 4096 and sign it with a root certficate then that would be a iintermediate certificate (Cross-Signing).

5

You are still very wrong about this.

Even Mikrotik's certificate on this forum website doesn't match the root.

That doesn't even make sense. A root CA private key doesn't generate keys.

An encryption key of 4096 does not generate any keys, it can't.

No, this is even worse than your previous statements.

Please stop trying to sound smart by making stuff up that "sounds good".

6

What are you talking about. You don't even know the basic certificate chain.

openssl s_client -connect mikrotik.com:443 
Connecting to 2a02:610:7501:2000::205
CONNECTED(00000003)
depth=2 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
verify return:1
depth=1 C=US, O=DigiCert Inc, CN=DigiCert EV RSA CA G2
verify return:1
depth=0 jurisdictionC=LV, businessCategory=Private Organization, serialNumber=40003286799, C=LV, L=Riga, O=SIA "Mikrotikls", CN=mikrotik.com
verify return:1
---
Certificate chain
 0 s:jurisdictionC=LV, businessCategory=Private Organization, serialNumber=40003286799, C=LV, L=Riga, O=SIA "Mikrotikls", CN=mikrotik.com
   i:C=US, O=DigiCert Inc, CN=DigiCert EV RSA CA G2
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jan  5 00:00:00 2026 GMT; NotAfter: Feb  5 23:59:59 2027 GMT
 1 s:C=US, O=DigiCert Inc, CN=DigiCert EV RSA CA G2
   i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Jul  2 12:42:50 2020 GMT; NotAfter: Jul  2 12:42:50 2030 GMT
---


[quote="kevinds, post:5, topic:271658"]
That doesn't even make sense. A root CA private key doesn't generate keys.
[/quote]

Basic certificate generation encryption key

openssl req -new -newkey rsa:4096 for Root CA

Create a web cerficate csr that can equal or less than 4096, like 3072 and signed with the Root CA.

I still stand by my statement.

Then create a web cerfificate and sign it with the iintermediate certificate.

Certificate chain - Root CA - iintermediate ca - web cerfificate. As long as you have the private keys.

I think you need to do more learning about certificates or you just don't understand.

But to answer your questioin. No you can't change the key size!

7

What are you? I said "This forum website" and you queried mikrotik.com not forum.mikrotik.com which is signed by LE.

Why? No seriously, why? This would just be wasting time.

I have RSA-8192 certificates on my Mikrotik routers signed by LE, trying to duplicate using the built-in client.

There is always more to learn about everything and I do have a pair of Luna HSMs for learning however RouterOS's limitations are just more half-baked features.

8

The certificate chain still points to CN=mikrotik.com

openssl s_client -connect forum.mikrotik.com:443 
Connecting to 2a02:610:7501:3000::244
CONNECTED(00000003)
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2
verify return:1
depth=2 C=US, O=ISRG, CN=Root YE
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YE1
verify return:1
depth=0 CN=mikrotik.com
verify return:1
---
Certificate chain
 0 s:CN=mikrotik.com
   i:C=US, O=Let's Encrypt, CN=YE1
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Jun 26 05:56:40 2026 GMT; NotAfter: Sep 24 05:56:39 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=YE1
   i:C=US, O=ISRG, CN=Root YE
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
---

I don't use them but LE does..

I'm gueesing LE gave you a cerfiicate chain and what formai PEM, DER, PKCS#7, P7B, PKCS#12.

Check the root certificate and see what LE used and what type of key they used. There is a YR3 but I can't find any info on that.

Why such a large key size of 8192?

Anyway, you won't be able to duplicate it as a LE certificate. You don't have the root key.

You can make a Root CA cerfificate with the key size of RSA-8192 but I wouldn't. It would be to much on the router. You should use only 2048 and 4096 is pushing it.

It would be better to use EC secp256r1. Smaller, faster and safer.

Edit: What I should have asked. How many certificates are in the certificate chain? Also, I didn't get into the public key that goes with the certificate. You really don't need a large encryption key cipher. It's not like a MT routers can do Tera flop per second.

9

I don't know whether it is formally required somewhere, but the logic behind the "the root CA key must be longest one or equal to the keys of all the other certificates in the chain of trust" is based on how the chain of trust works as a whole:

  • an attacker can get the public keys of all the certificates, it is enough to impersonate a TLS client and initiate a connection
  • if he can recover the private key of any of the authorities in the chain, he can sign his own fake certificate using that authority no matter what key length the actual one uses.

So why bother recovering the 8192-bit key of the endpoint certificate if he can use way less horsepower to recover the 2048-bit one of any of the intermediate authorities or the root one, and use it to sign a fake endpoint certificate with the same CN, SAN etc., hence indistinguishable from the "real" one for any recipient - unless the recipient would know the key ID of the real one in advance, but that defeats the purpose of using the chain of trust, normally the key ID changes on certificate renewal (exceptions exist).