Configuring an RSA root and intermediate X.509 CA

[polarathene]

One part I'm not familiar with a CA is if they're meant to only have/provide the single root/intermediate.

I know with LetsEncrypt that they use an RSA root for signing both RSA/ECDSA leaf certs, but they've talked about a full ECDSA chain, does that require the ACME client to interact with a different endpoint, or can the ACME client provide some hint once that would be available?

How would similar be achieved with step-ca? Two roots and intermediates...two instances? Looking at the ca.json perhaps it would be two provisioners? I'm not sure how the ACME provisioner in addition to those would be able to choose from an RSA or ECDSA root though? (EDIT: Looking at the docs for adding provisioners, this non-ACME provisioner that step ca init creates is unrelated to what I thought it was, seems to be for a provisioning API)

[tashian]

Hi @polarathene, I'm not sure how Let's Encrypt is going to do their full-chain ECDSA service, but with step-ca you will get ECDSA keys by default for your whole chain. If you wanted an RSA root instead of ECDSA, you can pass an existing RSA root cert and key to step ca init when you create the CA (eg. step ca init --root=root.crt --key=root.key) and it will use that to sign the intermediate.

Does this help?

[polarathene]

Haha, yes I was just about to ask if step certificate create is effectively what step ca init is using to create it's root and intermediates with.

So something like step certificate create root-ca root-ca.crt root-ca.key --kty RSA --profile root-ca.

with step-ca you will get ECDSA keys by default for your whole chain.

Yes I noticed that and that's really awesome :) I was only asking if I'm setting up a test suite for a popular open-source project (a docker packaged mail server), and I think for the legacy clients where we allow older TLS and ciphers some may not like ECDSA/ECDHE(ECC?), thus I'm not sure if an ECDSA root could cause compatibility issues for that niche, presumably a full RSA chain would be what they expect?

Does this help?

Almost, I was curious how a CA would cater to supporting full chain for either RSA or ECC(ECDSA? Sorry haven't quite got all the jargon right just yet). I've noticed in system trust stores that CAs tend to have multiple root certs, I've not inspected them yet, but perhaps they're differing by certain features such as key type?

Would the correct approach currently with the Docker image smallstep/step-ca be two containers, one initialized with RSA and the other ECDSA? I'm not familiar with ACME in-depth, so perhaps that does have a way to negotiate what root to use and a single instance of step-ca is all that's need.

[dopey]

Would the correct approach currently with the Docker image smallstep/step-ca be two containers, one initialized with RSA and the other ECDSA? I'm not familiar with ACME in-depth, so perhaps that does have a way to negotiate what root to use and a single instance of step-ca is all that's need.

The ACME protocol does not have a way to negotiate the signing certificate. For simplicity, in the short term, I would recommend just having one instance of step-ca where you have an RSA intermediate. You can use that to sign any certificate (ecsda, rsa, eddsa, etc.)

[maraino]

@polarathene If you want both root and intermediate to be an RSA key, you need to do:

# Create root as you pointed out
step certificate create root-ca root-ca.crt root-ca.key \
  --kty RSA --profile root-ca
# Create intermediate and sign it with root
step certificate create root-ca intermediate-ca.crt intermediate-ca.key \
  --kty RSA --profile intermediate-ca --ca root-ca.crt --ca-key root-ca.key

Once you have those, the easiest way would be just to run step ca init, and then replace "root", "crt", and "key" in the ca.json, with the root-ca.crt, intermediate-ca.crt and intermediate-ca.key you created before.

Take into account that the certificate that step-ca creates for itself would be an ECDSA, but that shouldn't be a problem, as long as the tools that talk with step-ca support ECDSA, and step does.

[polarathene]

Take into account that the certificate that step-ca creates for itself would be an ECDSA, but that shouldn't be a problem, as long as the tools that talk with step-ca support ECDSA, and step does.

This is referring to the certificate used for HTTPS communication to the CA? I believe I've referred to the root cert step-ca initialized with as a parameter/option for utilities making the requests (curl --cacert, python ENV var REQUESTS_CA_BUNDLE, acme.sh --ca-bundle, etc).

You only mention this due to the advice of modifying ca.json rather than step ca init options to set the root? I haven't checked locally yet, but assume step-ca would in the latter case use an RSA root if provided for HTTPS instead of generating the default ECDSA just for that?

[maraino]

@polarathene I mean the certificate used for HTTPS by step-ca. Right now, no matter what root/intermediate is used this is always an ECDSA certificate. The ACME client (acme.sh, certbot, step, ...) must support it.

If the ACME client is embedded in a server that does not support ECDSA, then it would be a problem, and a different approach should be used, i.e: use one of the ACME clients above.

You only mention this due to the advice of modifying ca.json rather than step ca init options to set the root?

step ca init would also create an ECDSA intermediate even if an RSA root is passed, that's why if you want to only use RSA keys in the chain, you need to overwrite the intermediate too.

[dopey]

step-ca doesn't support using different root/ intermediate keys for different provisioners at this time. As @tashian said, you can create a new root and intermediate chain using step certificate create --profile and replace the values in ca.json to use your newly created ones. But then all certificates will be signed using the new RSA keys.

[maraino]

@polarathene As @dopay says, provisioners do not support different chains. So if you want to support 2+ different intermediates sharing the same root or 2+ different chains you will need 2+ instances.

With 2+ different chains, you can add the root for instance2 as a federated certificate in the instance1, and the same the other way around. With that, you can use step ca federation to download a pem with all the roots in it.

[xiaofan8421]

Similarly, step-ca only can create one intermediate certificate/key pair for current business use? Namely, intermediate-self can be replaced in use, but not sign for multiple intermediate in production.

Background: If I need to sign different intermediate for for different internal business, using step-ca federation mode is recommended now? I try to sign for multiple intermediate, but it seems that step-ca not support it.

I read many official blogs or discussions, maybe here is the right place to talk about my concern.
I will appreciate it if I get your corresponding reply.
@maraino @tashian

[maraino]

As I said, one instance of step-ca can only be signed with one intermediate. But that intermediate can be signed by another intermediate (step-ca-intermediate-intermediate1-...-root). Multiple instances of step-ca (if multiple intermediates) sharing the same root are automatically compatible.

The federation's intention is to support multiple CAs with different roots. The command step ca federation will download all the roots configured in your instance. You decide how to use them.

I try to sign for multiple intermediate, but it seems that step-ca not support it.

For that, you need to use multiple instances; they can share the same root or not.

On the client side, if you want to manage multiple CAs simultaneously, I recommend using context.

# Bootstrap CA 1:
step ca bootstrap --context ca1 --ca-url https://ca1.example.com --fingerprint xxx
# Bootstrap CA 2:
step ca bootstrap --context ca2 --ca-url https://ca2.example.com --fingerprint yyy

# Current context
$ step context current
ca2
# List all the configured contexts
$ step context list
▶ca2
ca1
# Switch context
$ step context select ca1
✔ Context: ca1

[dopey]

My understanding, is step-ca root and intermediate certs are ECDSA based (shows up as signature algorithm when inspecting my leaf cert?), and public key algorithm is what the ACME client can choose, most default to RSA of some length, while some do support ECC (acmebot for example provisions both RSA and ECC certs by default).

There's a few conflating concepts here so I'll try to pull them apart a bit - note I'm no expert either. So, suppose you've initialized your PKI with a root and intermediate cert which are both ECDSA, as we do by default. That means that when you sign incoming certificate requests (CSRs) the signature algorithm on those new certificates will be some form of ecdsa sig algorithm. If you the user requests that the signature algorithm must be of some RSA type, step-ca will not be able to create a valid certificate, because it does not have an RSA intermediate certificate. Most leaf certificates do not request a particular signing algorithm (in my experience) but rather let the server decide the most appropriate algorithm based on the key the server is using to sign.

Now let's talk about CSRs briefly. When you generate a CSR you generate a public / private key pair and the public part of that pair is stored in the CSR. That key has no influence on the signing key or the signing algorithm. You could create a CSR using a RSA key, and your CA can sign that CSR using an ECDSA key. The signing key and the key in the CSR are two completely separate things.

So, your ACME client might generate CSRs with RSA keys, but you can still sign those using an ECDSA key (which step-ca does by default). Or if you'd prefer you can sign them using an RSA key. You just have to configure your CA to use RSA keys. Unless you have a particular need to use an RSA signature algorithm (e.g. some software doesn't support ecdsa signature algorithms), we recommend you use the defaults.

[polarathene]

Most leaf certificates do not request a particular signing algorithm (in my experience) but rather let the server decide the most appropriate algorithm based on the key the server is using to sign.

Ok, so it's similar to serving RSA or ECC leaf certs on a web server, which the client receives the certificate and may express preference (but not always respected) for negotiation of what cipher to use that is compatible with the certs public key type?

Now let's talk about CSRs briefly.

I've seen CSRs mentioned quite a bit while learning about all this, thanks for breaking that down. So a client won't care for or validate the signing key, only the public key? (The server in my case is for SMTP with Postfix or Dovecot, with third-party servers or clients to interact with)

Unless you have a particular need to use an RSA signature algorithm (e.g. some software doesn't support ecdsa signature algorithms), we recommend you use the defaults.

I don't personally, ECDSA is great for me. The project I'm contributing to however does need to support some legacy clients AFAIK, so to test against that I believe requires a full RSA chain?

---

I used acmebot to provision the following certificates, which have also included the full chain of intermediate and root certs:

Public Key ECC secp384r1 (leaf) - Signed ECDSA-SHA256 (root?)

$ openssl x509 -text -noout -in example.test+root.ecdsa.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0b:a4:0a:63:19:3f:6a:99:48:f3:2b:69:fc:3e:0f:15
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Smallstep Intermediate CA
        Validity
            Not Before: Sep 28 09:54:43 2020 GMT
            Not After : Sep 29 09:55:43 2020 GMT
        Subject: CN = example.test
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:e3:f0:ae:bd:cd:63:4d:62:72:8d:5b:26:d0:d8:
                    39:41:8a:4d:ab:fc:21:c8:60:67:7d:4f:63:11:5a:
                    9d:85:7b:db:6e:a8:33:e0:1a:a4:0e:95:c9:f9:67:
                    d0:be:75:d8:dd:6b:71:8f:1b:f9:9c:da:ad:79:4f:
                    ff:a8:ef:92:48:fa:88:c4:69:11:10:77:1d:21:e5:
                    3d:28:2c:ce:0e:18:7b:c4:9f:23:c7:7a:79:e4:c3:
                    0b:1b:70:6c:8e:45:c6
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier: 
                76:2B:FC:9D:1D:E5:D5:63:8D:2C:CB:C6:B8:B2:3D:5C:B6:8E:42:23
            X509v3 Authority Key Identifier: 
                keyid:8E:FB:31:1F:A7:15:2A:B6:CE:14:CE:92:7E:31:DF:3B:22:58:FB:5D

            X509v3 Subject Alternative Name: 
                DNS:example.test, DNS:mail.example.test
            1.3.6.1.4.1.37476.9000.64.1: 
                0......acme-example..
    Signature Algorithm: ecdsa-with-SHA256
         30:46:02:21:00:ec:9f:30:8c:bc:c5:9f:e9:fb:f5:ad:fc:ed:
         a5:3d:53:1b:1e:3e:c3:7a:93:f1:4a:e7:ce:c7:5c:1c:37:4c:
         ad:02:21:00:99:73:e6:54:87:d9:33:a9:ba:2a:52:db:6b:e4:
         34:d0:96:88:26:79:5e:99:ec:25:f6:f6:39:8e:10:97:a7:3e

Public Key RSA 4096-bit (leaf) - Signed ECDSA-SHA256 (root?)

$ openssl x509 -text -noout -in example.test+root.rsa.pem  

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            51:8c:80:48:22:a4:95:09:14:a9:36:94:09:54:84:8a
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Smallstep Intermediate CA
        Validity
            Not Before: Sep 28 08:40:28 2020 GMT
            Not After : Sep 29 08:41:28 2020 GMT
        Subject: CN = example.test
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:b3:dc:d1:c0:1d:5d:0e:fb:e1:9c:90:44:e1:3a:
                    0b:63:88:5d:ac:c8:c8:b3:bc:da:d1:40:15:90:a4:
                    b6:88:c7:58:aa:98:7c:f3:c1:7b:a3:4a:da:da:7e:
                    6c:c3:f8:c6:2a:fc:87:08:09:e5:58:da:bf:f2:35:
                    e1:ac:8c:99:c7:c9:6a:d9:02:b3:79:47:24:68:f6:
                    0b:20:2e:cd:e6:2c:e6:fe:fd:06:0c:96:f6:7e:08:
                    72:f6:d8:e5:82:66:31:d9:c3:37:81:ea:94:56:83:
                    b7:1b:d4:e2:ba:bb:71:a3:54:66:58:84:78:aa:6c:
                    05:8b:05:50:2c:cc:ed:45:ad:f5:28:49:be:12:2d:
                    d7:0a:f7:fd:71:37:ee:96:b0:c0:a9:fc:2e:1b:92:
                    2b:3a:04:89:39:ac:5f:64:48:11:c0:a4:46:5f:dc:
                    0b:78:65:45:b3:9d:2a:01:4b:4d:d8:c0:1e:64:97:
                    86:2a:b7:8b:81:79:18:51:ef:13:1e:1d:2d:2b:fa:
                    08:85:17:6a:16:28:ff:bd:cb:8f:6f:fa:06:16:ab:
                    1d:63:1f:53:1c:64:b4:66:27:bc:7a:03:bd:46:37:
                    bd:31:3e:75:ff:c4:82:80:2d:fb:08:7c:8f:92:17:
                    65:47:8b:3f:90:ed:71:8a:1c:e4:1f:9c:e2:c1:d5:
                    3c:57:04:e4:b4:87:37:8b:6e:72:db:1f:44:d5:3a:
                    14:ab:dc:dd:74:9b:fa:57:f1:bf:8d:03:9d:ae:8a:
                    75:6f:d7:be:71:0e:7f:88:53:96:17:3d:e7:97:13:
                    0f:4d:24:6d:fa:13:24:8f:e2:57:6a:4c:92:d7:f3:
                    1c:05:f3:38:3c:2a:57:8b:d3:0a:56:f9:6d:77:e0:
                    ee:21:de:68:71:d9:89:a0:cf:5a:5d:2d:c1:94:43:
                    18:83:d7:3d:62:27:78:63:ca:85:47:06:2f:2c:c0:
                    fb:7d:bc:69:d5:c9:3a:4c:67:c7:08:75:6e:80:93:
                    6a:9d:f0:74:eb:74:66:bf:0b:32:02:a6:17:b0:58:
                    ad:31:a1:ad:c4:e5:d0:ac:19:9b:71:0b:f9:50:68:
                    79:69:d9:53:6b:13:81:82:e7:8d:4b:06:40:3c:44:
                    b3:08:f9:d6:84:9e:3c:dd:1b:5e:cb:e8:b3:d6:67:
                    82:81:d4:b1:2d:b2:30:eb:0d:fe:80:62:89:db:fa:
                    8e:ea:51:22:b5:13:df:80:27:35:9a:3e:37:80:5a:
                    83:83:ba:78:52:94:75:87:84:ee:f9:13:1f:f0:34:
                    7e:21:68:ad:2d:ab:83:fc:29:5c:38:1a:c2:4a:a7:
                    62:67:91:41:7c:8b:85:15:f1:36:e6:57:db:c2:74:
                    27:ce:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier: 
                70:1B:BB:5E:95:73:A4:BA:C4:BC:49:5B:52:FE:DF:78:45:26:D8:02
            X509v3 Authority Key Identifier: 
                keyid:8E:FB:31:1F:A7:15:2A:B6:CE:14:CE:92:7E:31:DF:3B:22:58:FB:5D

            X509v3 Subject Alternative Name: 
                DNS:example.test, DNS:mail.example.test
            1.3.6.1.4.1.37476.9000.64.1: 
                0......acme-example..
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:69:e5:7e:dd:be:40:8e:ec:18:9a:68:26:35:37:
         f2:88:c1:91:8f:6e:1a:68:30:0f:60:04:09:d8:6b:d0:f0:3a:
         02:20:34:5d:02:d3:3d:08:14:ab:97:9e:e3:f9:ee:53:a8:ae:
         7e:ac:b3:a3:ba:b6:58:87:0f:54:a1:29:99:b3:16:6a

Contents of example.test+root.rsa.pem

example.test issued at 2020-09-28 08:40:28 UTC
-----BEGIN CERTIFICATE-----
MIIDyTCCA3CgAwIBAgIQUYyASCKklQkUqTaUCVSEijAKBggqhkjOPQQDAjAkMSIw
IAYDVQQDExlTbWFsbHN0ZXAgSW50ZXJtZWRpYXRlIENBMB4XDTIwMDkyODA4NDAy
OFoXDTIwMDkyOTA4NDEyOFowFzEVMBMGA1UEAxMMZXhhbXBsZS50ZXN0MIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAs9zRwB1dDvvhnJBE4ToLY4hdrMjI
s7za0UAVkKS2iMdYqph888F7o0ra2n5sw/jGKvyHCAnlWNq/8jXhrIyZx8lq2QKz
eUckaPYLIC7N5izm/v0GDJb2fghy9tjlgmYx2cM3geqUVoO3G9Tiurtxo1RmWIR4
qmwFiwVQLMztRa31KEm+Ei3XCvf9cTfulrDAqfwuG5IrOgSJOaxfZEgRwKRGX9wL
eGVFs50qAUtN2MAeZJeGKreLgXkYUe8THh0tK/oIhRdqFij/vcuPb/oGFqsdYx9T
HGS0Zie8egO9Rje9MT51/8SCgC37CHyPkhdlR4s/kO1xihzkH5ziwdU8VwTktIc3
i25y2x9E1ToUq9zddJv6V/G/jQOdrop1b9e+cQ5/iFOWFz3nlxMPTSRt+hMkj+JX
akyS1/McBfM4PCpXi9MKVvltd+DuId5ocdmJoM9aXS3BlEMYg9c9Yid4Y8qFRwYv
LMD7fbxp1ck6TGfHCHVugJNqnfB063RmvwsyAqYXsFitMaGtxOXQrBmbcQv5UGh5
adlTaxOBgueNSwZAPESzCPnWhJ483Rtey+iz1meCgdSxLbIw6w3+gGKJ2/qO6lEi
tRPfgCc1mj43gFqDg7p4UpR1h4Tu+RMf8DR+IWitLauD/ClcOBrCSqdiZ5FBfIuF
FfE25lfbwnQnztkCAwEAAaOBxTCBwjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBRwG7telXOkusS8SVtS/t94
RSbYAjAfBgNVHSMEGDAWgBSO+zEfpxUqts4UzpJ+Md87Ilj7XTAqBgNVHREEIzAh
ggxleGFtcGxlLnRlc3SCEW1haWwuZXhhbXBsZS50ZXN0MCUGDCsGAQQBgqRkxihA
AQQVMBMCAQYEDGFjbWUtZXhhbXBsZQQAMAoGCCqGSM49BAMCA0cAMEQCIGnlft2+
QI7sGJpoJjU38ojBkY9uGmgwD2AECdhr0PA6AiA0XQLTPQgUq5ee4/nuU6iufqyz
o7q2WIcPVKEpmbMWag==
-----END CERTIFICATE-----

Smallstep Intermediate CA
-----BEGIN CERTIFICATE-----
MIIBpDCCAUqgAwIBAgIQYqjqhE10HxvoqhJbTGi+SDAKBggqhkjOPQQDAjAcMRow
GAYDVQQDExFTbWFsbHN0ZXAgUm9vdCBDQTAeFw0yMDA5MjgwNzQxMTZaFw0zMDA5
MjYwNzQxMTZaMCQxIjAgBgNVBAMTGVNtYWxsc3RlcCBJbnRlcm1lZGlhdGUgQ0Ew
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ0rG4ztnIzwlfAM4gJq3wBOnsGqaFU
ZW0CjQ6hFyiNvzvKnE9exX3CX+4jpYgJCD7yL0t3+AeWbuakOAyq/Ot4o2YwZDAO
BgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUjvsx
H6cVKrbOFM6SfjHfOyJY+10wHwYDVR0jBBgwFoAUrgr2pbahe4hUEXBR+xbP+keK
RuIwCgYIKoZIzj0EAwIDSAAwRQIgcjK42dNVYdpd0RdvWrGSyDbTqzNMKNAjLxR1
F5rq/E8CIQCVHT6GLOnJXbyPoUA3IF5moJG8FyluvKaUpFEAeiMH/g==
-----END CERTIFICATE-----

Smallstep Root CA
-----BEGIN CERTIFICATE-----
MIIBezCCASGgAwIBAgIQO2kJ82xU3TMsRJQSdxaIjDAKBggqhkjOPQQDAjAcMRow
GAYDVQQDExFTbWFsbHN0ZXAgUm9vdCBDQTAeFw0yMDA5MjgwNzQxMTZaFw0zMDA5
MjYwNzQxMTZaMBwxGjAYBgNVBAMTEVNtYWxsc3RlcCBSb290IENBMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEbGNeLTPP7DlY7mspSOmSDLIq0lpoK4BYiQl1KYPW
qqwLaKZ9pp3G5sN3e/x6XBy2cpx54R8N65GJy6q7CO7x36NFMEMwDgYDVR0PAQH/
BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFK4K9qW2oXuIVBFw
UfsWz/pHikbiMAoGCCqGSM49BAMCA0gAMEUCIDEY3LExj98V6lLblI7Yx0LTAwuK
0E8n6TEZLhJeWdHtAiEAhYaRVRJFYJGFc8v2wzA0dNwh9SiO6ziOTOLMyxouDFg=
-----END CERTIFICATE-----

-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAhBDl8FI5dnBsWNHQR2g6q5DZvZ36TOS+qbQ546aF0ZlnCYJsgrzu
FIbW9K/OdZa45tt5b8vl2RRl2+Rf882Z+r5q8hAU4f7CjHBYqtsc/QMc7JzD1pIH
ZT4FnglAt+2S1DTyh7EEhgxn7JZkGmsY8w3gt93ZW7s2Skl94+MU8zErFB3dfwea
r6+CbH/ioyLwxpcEVzxD8VxkpMl2n42BPFQ5i85nB0Lod9LEe2nMMItEERGrxiE9
mBIRLDN/NUNFV3EC7xDfUxCPVROcjCdsNGi21GdQsFO0XjSO3XfGfX6HI+gq+dbn
eC89w/0wS+LT/lwbGXgc470C0RR0Q5St8wIBAg==
-----END DH PARAMETERS-----

-----BEGIN EC PARAMETERS-----
BgUrgQQAIw==
-----END EC PARAMETERS-----
-----BEGIN EC PARAMETERS-----
BgUrgQQAIg==
-----END EC PARAMETERS-----
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----

Note, presently step certificate inspect will fail with the above with an "contains invalid PEM block" error, remove the first line to get the following output similar to the openssl command used earlier:

step certificate inspect example.test+root.rsa.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 108396991082351487982507170275207185546 (0x518c804822a4950914a936940954848a)
    Signature Algorithm: ECDSA-SHA256
        Issuer: CN=Smallstep Intermediate CA
        Validity
            Not Before: Sep 28 08:40:28 2020 UTC
            Not After : Sep 29 08:41:28 2020 UTC
        Subject: CN=example.test
        Subject Public Key Info:
            Public Key Algorithm: RSA
                Public-Key: (4096 bit)
                Modulus:
                    b3:dc:d1:c0:1d:5d:0e:fb:e1:9c:90:44:e1:3a:0b:
                    63:88:5d:ac:c8:c8:b3:bc:da:d1:40:15:90:a4:b6:
                    88:c7:58:aa:98:7c:f3:c1:7b:a3:4a:da:da:7e:6c:
                    c3:f8:c6:2a:fc:87:08:09:e5:58:da:bf:f2:35:e1:
                    ac:8c:99:c7:c9:6a:d9:02:b3:79:47:24:68:f6:0b:
                    20:2e:cd:e6:2c:e6:fe:fd:06:0c:96:f6:7e:08:72:
                    f6:d8:e5:82:66:31:d9:c3:37:81:ea:94:56:83:b7:
                    1b:d4:e2:ba:bb:71:a3:54:66:58:84:78:aa:6c:05:
                    8b:05:50:2c:cc:ed:45:ad:f5:28:49:be:12:2d:d7:
                    0a:f7:fd:71:37:ee:96:b0:c0:a9:fc:2e:1b:92:2b:
                    3a:04:89:39:ac:5f:64:48:11:c0:a4:46:5f:dc:0b:
                    78:65:45:b3:9d:2a:01:4b:4d:d8:c0:1e:64:97:86:
                    2a:b7:8b:81:79:18:51:ef:13:1e:1d:2d:2b:fa:08:
                    85:17:6a:16:28:ff:bd:cb:8f:6f:fa:06:16:ab:1d:
                    63:1f:53:1c:64:b4:66:27:bc:7a:03:bd:46:37:bd:
                    31:3e:75:ff:c4:82:80:2d:fb:08:7c:8f:92:17:65:
                    47:8b:3f:90:ed:71:8a:1c:e4:1f:9c:e2:c1:d5:3c:
                    57:04:e4:b4:87:37:8b:6e:72:db:1f:44:d5:3a:14:
                    ab:dc:dd:74:9b:fa:57:f1:bf:8d:03:9d:ae:8a:75:
                    6f:d7:be:71:0e:7f:88:53:96:17:3d:e7:97:13:0f:
                    4d:24:6d:fa:13:24:8f:e2:57:6a:4c:92:d7:f3:1c:
                    05:f3:38:3c:2a:57:8b:d3:0a:56:f9:6d:77:e0:ee:
                    21:de:68:71:d9:89:a0:cf:5a:5d:2d:c1:94:43:18:
                    83:d7:3d:62:27:78:63:ca:85:47:06:2f:2c:c0:fb:
                    7d:bc:69:d5:c9:3a:4c:67:c7:08:75:6e:80:93:6a:
                    9d:f0:74:eb:74:66:bf:0b:32:02:a6:17:b0:58:ad:
                    31:a1:ad:c4:e5:d0:ac:19:9b:71:0b:f9:50:68:79:
                    69:d9:53:6b:13:81:82:e7:8d:4b:06:40:3c:44:b3:
                    08:f9:d6:84:9e:3c:dd:1b:5e:cb:e8:b3:d6:67:82:
                    81:d4:b1:2d:b2:30:eb:0d:fe:80:62:89:db:fa:8e:
                    ea:51:22:b5:13:df:80:27:35:9a:3e:37:80:5a:83:
                    83:ba:78:52:94:75:87:84:ee:f9:13:1f:f0:34:7e:
                    21:68:ad:2d:ab:83:fc:29:5c:38:1a:c2:4a:a7:62:
                    67:91:41:7c:8b:85:15:f1:36:e6:57:db:c2:74:27:
                    ce:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                Server Authentication, Client Authentication
            X509v3 Subject Key Identifier:
                70:1B:BB:5E:95:73:A4:BA:C4:BC:49:5B:52:FE:DF:78:45:26:D8:02
            X509v3 Authority Key Identifier:
                keyid:8E:FB:31:1F:A7:15:2A:B6:CE:14:CE:92:7E:31:DF:3B:22:58:FB:5D
            X509v3 Subject Alternative Name:
                DNS:example.test, DNS:mail.example.test
            X509v3 Step Provisioner:
                Type: ACME
                Name: acme-example
    Signature Algorithm: ECDSA-SHA256
         30:44:02:20:69:e5:7e:dd:be:40:8e:ec:18:9a:68:26:35:37:
         f2:88:c1:91:8f:6e:1a:68:30:0f:60:04:09:d8:6b:d0:f0:3a:
         02:20:34:5d:02:d3:3d:08:14:ab:97:9e:e3:f9:ee:53:a8:ae:
         7e:ac:b3:a3:ba:b6:58:87:0f:54:a1:29:99:b3:16:6a

Unlike with openssl I see that X509v3 Step Provisioner is properly displayed. I assume due to it being a non-standard extension that openssl wouldn't recognize hence it's broken output for that part?

[tashian]

The project I'm contributing to however does need to support some legacy clients AFAIK, so to test against that I believe requires a full RSA chain?

Yeah, if you wanted to test against a legacy client that expects public web PKI-style certificate chains, you'd probably want to use a full RSA chain. The default settings for step-ca are pretty different from Web PKI (eg. it issues short-lived certificates and uses passive revocation, it uses ECDSA keys), but you could configure it to simulate some of the Web PKI scenarios you'd see in the wild. You may end up needing a few different CA configurations if you really want a broad test suite.