[Bug]: scep provisioner returns root and intermediate certificate despite --exclude-intermediate flag set

[williamhargrove]

Steps to Reproduce

Create a SCEP provisioner (as per the example provisioner within the smallstep documentation) and then update, setting the following flags:

        --include-root
        --exclude-intermediate

The output of the provisioner is as below:

{
      "type": "SCEP",
      "name": "SCEP",
      "forceCN": true,
      "challenge": "*** REDACTED ***",
      "includeRoot": true,
      "excludeIntermediate": true,
      "minimumPublicKeyLength": 2048,
      "decrypterCertificate": "KioqIFJFREFDVEVEICoqKg==",
      "decrypterKeyPEM": "KioqIFJFREFDVEVEICoqKg==",
      "decrypterKey": "*** REDACTED ***",
      "decrypterKeyPassword": "*** REDACTED ***",
      "encryptionAlgorithmIdentifier": 2,
      "options": {
        "x509": {

        },
        "ssh": {

        }
      },
      "claims": {
        "minTLSCertDuration": "336h0m0s",
        "maxTLSCertDuration": "2160h0m0s",
        "defaultTLSCertDuration": "2160h0m0s",
        "enableSSHCA": false,
        "disableRenewal": false,
        "allowRenewalAfterExpiry": false,
        "disableSmallstepExtensions": false
      }
    }

With this configuration I would expect just the root CA cert to be returned.

Using a scep client under linux, get the CA cert,

./sscep getca -c test -u http://red.act.ed/scep/SCEP

This call will return both the root and intermediate certificate.

Your Environment

• OS - Docker container (Alpine Linux v3.20)
• step-ca Version - step-ca:0.28.1

Expected Behavior

Using a scep client under linux, get the CA cert,

./sscep getca -c test -u http://red.act.ed/scep/SCEP

This call will return both the root and intermediate certificate.

I would have expected this to return just the root CA

Actual Behavior

Two certificates are returned, the root and the intermediate.

Additional Context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[hslatman]

Hey @williamhargrove,

Why do you need the intermediate to be excluded? By default that's the certificate a SCEP client picks to encrypt a PKCS7 message to, so generally it should be included. The CA won't be able to decrypt messages that are encrypted to the root CA certificate in its current form.

The logic for excluding the intermediate is conditional:

certificates/scep/authority.go

Lines 147 to 184 in 9d3b78a

	// GetCACertificates returns the certificate (chain) for the CA.
	//
	// This methods returns the "SCEP Server (RA)" certificate, the issuing CA up to and excl. the root.
	// Some clients do need the root certificate however; also see: https://github.com/openxpki/openxpki/issues/73
	//
	// In case a provisioner specific decrypter is available, this is used as the "SCEP Server (RA)" certificate
	// instead of the CA intermediate directly. This uses a distinct instance of a KMS for doing the SCEP key
	// operations, so that RSA can be used for just SCEP.
	//
	// Using an RA does not seem to exist in https://tools.ietf.org/html/rfc8894, but is mentioned in
	// https://tools.ietf.org/id/draft-nourse-scep-21.html.
	func (a *Authority) GetCACertificates(ctx context.Context) (certs []*x509.Certificate, err error) {
	p := provisionerFromContext(ctx)
	// if a provisioner specific RSA decrypter is available, it is returned as
	// the first certificate.
	if decrypterCertificate, _ := p.GetDecrypter(); decrypterCertificate != nil {
	certs = append(certs, decrypterCertificate)
	}
	// the CA intermediate is added to the chain by default. It's possible to
	// exclude it from being added through configuration. This can be useful in
	// environments where the SCEP client doesn't select the right RSA decrypter
	// certificate, resulting in the wrong recipient in the PKCS7 message.
	if p.ShouldIncludeIntermediateInChain() || len(certs) == 0 {
	// TODO(hs): ensure logic is in place that checks the signer is the first
	// intermediate and that there are no double certificates.
	certs = append(certs, a.intermediates...)
	}
	// the CA roots are added for completeness when configured to do so. Clients
	// are responsible to select the right cert(s) to store and use.
	if p.ShouldIncludeRootInChain() {
	certs = append(certs, a.roots...)
	}
	return certs, nil
	}

, and thus depends on a decrypter certificate to be set. The reason we included the setting is to be able to remove the intermediate from being returned to the SCEP client which affected some very specific edge case.

[williamhargrove]

@hslatman - so I am trying to debug an issue with an HP ilo (light out management card) that can use SCEP to issue certs for https:// based ilo access (so quite a specific use case)

I've posted into the smallstep discord channels, but at the moment I have not been able to get the HP ilo to successfully request a SCEP cert, and research so far suggests the issue is with the intermediate cert being returned. But I am a little in the dark and there are no client logs available (etc..)

So I wanted to exclude the intermediate cert from being returned and see if that lead to a change in behaviour.

[hslatman]

Could you try it with a decrypter certificate set instead? If one's available, you'll be able to exclude the intermediate.

Returning just the root (by excl. the intermediate, and not having the decrypter) won't work, as the CA does not have the capability to decrypt using the root CA certificate.

[williamhargrove]

Sure - will give this a try and get back to you. Thanks.

[williamhargrove]

Just to follow up on this - I have tried with a decrypter cert - but still get the same error on the client side (ie the HP ilo). After a call with HP, they have confirmed that automatic certificate issuance to the ilo does not work when you have an intermediate certificate issuing a leaf cert, only when a root CA issues the cert.

I'll close this now - thanks for the assistance.

[hslatman]

Just to follow up on this - I have tried with a decrypter cert - but still get the same error on the client side (ie the HP ilo). After a call with HP, they have confirmed that automatic certificate issuance to the ilo does not work when you have an intermediate certificate issuing a leaf cert, only when a root CA issues the cert.

I'll close this now - thanks for the assistance.

Thank you for testing, @williamhargrove!

I'm curious as to why it only works with root certificates, as it sounds like a big limitation requiring the root key to be "online". I can see it working in certain deployments and use cases, but I'd refrain from doing it like that in these times.

One thing you could try is to configure the root certificate as the intermediate (and leave it as the root too); without a decrypter. That way you would have a single tier CA, with the root signing the leafs directly. This is an unsupported configuration, and I don't remember trying it myself, but it might be worth a shot.