bootstrap-step-ca.sh: give SCEP provisioners an RSA decrypter (fix 14003)#48
Merged
Conversation
…003) The CA is EC, so step-ca cannot auto-use the CA key as the SCEP decrypter. The provisioner-add loop omitted an explicit decrypter, so newly-created SCEP provisioners returned only the CA cert on GetCACert (x-x509-ca-cert) instead of the CA+RA chain (x-x509-ca-ra-cert). macOS SCEP then can't encrypt its request and fails with MDM-SCEP:14003 "unable to generate certificate signing request". Hit 2026-07 on the tart-VM + arm64 provisioners added by the recent run; pre-existing provisioners worked because they already had a decrypter. Fix: ensure one shared RSA decrypter and pass it to every SCEP provisioner add (--scep-decrypter-certificate / --scep-decrypter-key). Reuse the existing decrypter from ca.json if the CA already has SCEP provisioners (keeps them consistent), else mint a new CA-signed RSA decrypter. The live CA was already remediated out-of-band (shared decrypter copied into the 6 affected provisioners + restart); this makes a from-scratch CA rebuild reproduce the working state instead of silently reintroducing the bug.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CA is EC, so step-ca can't auto-use the CA key as the SCEP decrypter. The provisioner-add loop never passed an explicit decrypter, so newly-created SCEP provisioners returned only the CA cert on
GetCACert(application/x-x509-ca-cert) instead of the CA+RA chain (x-x509-ca-ra-cert). macOS SCEP needs the RA (decrypter) cert to encrypt its request, so it failed withMDM-SCEP:14003"unable to generate certificate signing request".Hit 2026-07 on the tart-VM (
scep-gecko-t-osx-1500-m-vms) + the arm64 provisioners added by the recent run; the pre-existing provisioners (scep-no-sip, etc.) worked because they already had a decrypter.Fix: ensure one shared RSA decrypter and pass it to every SCEP
provisioner add(--scep-decrypter-certificate/--scep-decrypter-key). Reuse the decrypter already inca.jsonif the CA has SCEP provisioners (keeps them all consistent), else mint a new CA-signed RSA decrypter.Live CA already remediated out-of-band (shared decrypter copied into the 6 affected provisioners +
step-carestart; confirmedGetCACertnow returns the RA chain and enrollment succeeds with the correct SPIFFE role). This PR makes a from-scratch CA rebuild reproduce the working state instead of silently reintroducing the bug.Validated:
bash -nclean. The--scep-decrypter-*flag names + the mint path should be confirmed on the next from-scratch bootstrap (the reuse path is what runs on the existing CA).