The scep-submit helper is using an invalid operation to retrieve the CA Cert chain. It's using GetCAChain which returns a 400 error from EJBCA. When I patch and recompile it to use GetCACertChain instead, it is successful with a 200 response.
See section 5.6 of the draft from any of these versions:
https://tools.ietf.org/html/draft-nourse-scep-03
https://tools.ietf.org/html/draft-nourse-scep-04
https://tools.ietf.org/html/draft-nourse-scep-05
https://tools.ietf.org/html/draft-nourse-scep-06
https://tools.ietf.org/html/draft-nourse-scep-07
https://tools.ietf.org/html/draft-nourse-scep-08
https://tools.ietf.org/html/draft-nourse-scep-09
https://tools.ietf.org/html/draft-nourse-scep-10
https://tools.ietf.org/html/draft-nourse-scep-11
https://tools.ietf.org/html/draft-nourse-scep-12
https://tools.ietf.org/html/draft-nourse-scep-13
https://tools.ietf.org/html/draft-nourse-scep-14
https://tools.ietf.org/html/draft-nourse-scep-15
https://tools.ietf.org/html/draft-nourse-scep-16
https://tools.ietf.org/html/draft-nourse-scep-17
https://tools.ietf.org/html/draft-nourse-scep-18
I was unable to find any version of this document that mentions a GetCAChain operation.
I've patched and tested mine with this patch and I was able to get past the errors about a missing RA certificate.
--- a/src/scep.c +++ b/src/scep.c @@ -64,7 +64,7 @@ #define OP_GET_CA_CAPS "GetCACaps" #define OP_GET_CA_CERT "GetCACert" -#define OP_GET_CA_CHAIN "GetCAChain" +#define OP_GET_CA_CHAIN "GetCACertChain" #define OP_GET_INITIAL_CERT "PKIOperation" #define OP_PKCSREQ "PKIOperation" enum known_ops {
According to the draft there is a way to be backwards compatible with this. See: https://tools.ietf.org/html/draft-nourse-scep-18#section-5.6.3 My patch does not cover backwards compatibility.
Yup, you're totally right. It was even spelled correctly in the design docs, but I must have misremembered it when working the logic into scep.c.
The bit about only querying GetCACertChain is a little messy because the scep-submit helper currently expects the daemon to parse everything, so it doesn't have information about whether or not the certificate is self-signed or issued by a trusted issuer. With just the change you're describing, are you still seeing other breakage, or spurious errors being logged, or neither?
Either way, the name of the request should be fixed shortly.
The other odd thing is that I have to URL encode the data passed into the -i value. I think scep-submit should be URL encoding the data for me. If you feel like fixing that too, then that would be great, otherwise I'll just keep URL encoding the value I pass.
That's an oversight alright, but I'm hesitant to add the fix for fear of breaking people who've already worked around it. Anecdotally, how hard would it be for you, for example, to adapt to not working around it?
As long as there was something in the release notes when I upgraded, I think it would be fine. Or just add a new option that turns the urlencoding on
Just noticed that this bug is fixed in HEAD since June 2016. I had detected that bug and jgarland79 had opened the ticket. So building to HEAD fixed my problem. Thanks, Nalin.
Metadata Update from @jgarland79: - Issue set to the milestone: 0.0 NEEDS_TRIAGE
This is an issue against the current FreeIPA SCEP server using the latest published EL build (certmonger-0.78.4-3.el7.x86_64).
Are there plans on getting this fixed and released in the near future?
You'd have to file a bug with Red Hat against RHEL 7 asking for a backport.
Metadata Update from @rcritten: - Issue close_status updated to: None
Fixed with commit 71545541e5064281f913d91a08b7352af7fe6899 in 0.79
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue set to the milestone: 0.79 (was: 0.0 NEEDS_TRIAGE) - Issue status updated to: Closed (was: Open)