#103 Drop message from GetCACaps and GetCACert to improve spec compliance
Closed: fixed a year ago by rcritten. Opened 3 years ago by rcritten.

The gutmann 10 spec doesn't provide for message=<ca ident> at all and in the nourse 23 spec it is optional. It gets set to 0 by default and is messing up the EJBCA appliance CA server as it interprets 0 as the CA identifier which doesn't exist.

Also drop GetCACertChain as it doesn't exist in any of the current SCEP specifications.


Metadata Update from @rcritten:
- Issue assigned to rcritten
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

3 years ago

@rcritten - this fix appears (at first glance/troubleshooting) to be breaking our integration with Active Directory's NDES (scep) server.

[root@ip-10-0-0-0 ~]# /usr/libexec/certmonger/scep-submit -c ndes-ca -u https://example.com/certsrv/mscep/mscep.dll/ -R /tmp/ca_chain.pem -v
GET "https://example.com/certsrv/mscep/mscep.dll/?operation=GetCACaps"
response_code = 200
content-type = ""
code = 0
code_text = "No error"
results = ""
Internal error: no response to "https://example.com/certsrv/mscep/mscep.dll/?operation=GetCACaps".

In the previous patch version, we see the url appended with &message=0
Is there another setting we're missing somewhere? Otherwise this is breaking our configuration.

We're on CentOS 7 and we see that the latest version just went up from 0.78.4-11 (worked) to 0.78.4.12 (broken). Looking here, this may be completely unrelated to this specific issue, but the symptom looks like the issue outlined here. We'll keep investigating and see if we can't get to a more modern version in general, since 0.78.4 appears to be 4 years old already... :-(

I can't reproduce.

[root] # rpm -q certmonger-0.78.4-12.el7.x86_64

[root] # /usr/libexec/certmonger/scep-submit -u http://child-dc/certsrv/mscep/mscep.dll/pkiclient.exe -c -v
GET "http://child-dc/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACaps"
response_code = 200
content-type = "text/plain"
code = 0
code_text = "No error"
results = "UE9TVFBLSU9wZXJhdGlvbgpSZW5ld2FsClNIQS01MTIKU0hBLTI1NgpTSEEtMQpERVMz"
POSTPKIOperation
Renewal
SHA-512
SHA-256
SHA-1
DES3

Don't be confused by version numbers. This is not the same as upstream 0.78.4.

Would it matter that you are using http versus we're using https?

I very much doubt it. If it had been an issue with TLS you wouldn't have been able to connect at all.

Good point. Last observation is what we see in response from the old versus new messages. Not sure if this is anything, unless there is something with our NDES setup? I'll engage that team next...

[centos@ip-10-0-0-0 ~]$ curl https://example.com/certsrv/mscep/mscep.dll/?operation=GetCACaps
[centos@ip-10-0-0-0 ~]$ curl https://example.com/certsrv/mscep/mscep.dll/?operation=GetCACaps&message=0
[1] 14208

@rcritten - update on the inquiry above - we opened a ticket with Microsoft and their response is as follows, in reference to the SCEP RFC

The MESSAGE MAY be omitted, or it MAY be a string that represents the certification authority issuer identifier only with GetCACert but is not optional for GetCACaps.
C.1. GetCACaps HTTP Message Format
"GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT

I found a bug for that tool where it seems they removed “&message” in certain circumstances : https://bugzilla.redhat.com/show_bug.cgi?id=1608781
You have to contact them in order to fix this behavior as the &message= is expected as per RFC.

I’m saying that ndes server expects to get the "&message=" CA-IDENT in the request, and that “bug” 1608781 seems indicating that the tool should not be including message when it does not have a valid ca ident, which is leading to your error.
So yes, in fact our NDES server needs it.

Metadata Update from @rcritten:
- Issue status updated to: Open (was: Closed)

2 years ago

certmonger implements the guttman spec and there are a few differences.

And it being still an RFC there are some clarity issues.

I took this section:

3.5.1.  GetCACaps HTTP Message Format

   This message requests capabilities from a CA, with the format:

   "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF

to mean that no message is required. This is expanded on in 4.1 stating that it is. I guess I missed it.

There is no definition of what this value should be if a user doesn't request a specific identifier. sscep uses the string "CAIdentifier" and certmonger used to use 0. Why this blew up the EJBCA appliance I don't know, out of spec I presume, but there have been 16 revisions of gutmann and like 23 of nourse, so maybe it was valid at some point in time.

I can look to add this option back and allow an empty value if desired so that message is not sent for the EJBCA case.

If you have a Red Hat service agreement I'd suggest you open a case regarding this.

I just opened a case with RedHat as well - thanks a lot for the quick feedback, @rcritten!

I just opened a case with RedHat as well - thanks a lot for the quick feedback, @rcritten!

@jremitz -- I have just run into the same issue and did extensive testing. 100% the lack of the message parameter breaks connection to the Microsoft CA. The scep-submit utility takes a -i parameter to provide a CA identifier. It would be great if the the message parameter could be provided if/when the -i parameter is specified. I would be very interested in how your case with Red Hat goes. For now I guess we have to restrict our certmonger version to 0.78.4-11.

@ljkimmel - RedHat acknowledged the bug and said they were aware of it. They asked some follow up questions on our AD server version and asked if we tried a different URI, which is the one we were using above. We tried that and the one from rcritten with no success.

@jremitz - Based on the output of scep-submit I was able to craft direct cURL requests and none ever returned data unless the message parameter was passed. It appears that the value of the message parameter is inconsequential. I used various numbers and random strings like pickle. All returned data.

@rcritten -- It appears that you are essentially going to revert prior to this last change? Can't you just construct the string based on whether and ID was actually provided by the user? That way you're not always sending a default and breaking one system but also not always NOT sending the value and breaking another system (MS-CA).

Also, I see that you removed the operation for GetCACertChain. This was a valid and needed operation for the Microsoft CA. Can you also restore that?

The nourse spec in particular is very clear that message= is required for GetCACaps. It is implicit in guttman. nourse makes message optional for GetCACert.

As near I can tell GetCACertChain was never in guttman and was dropped in revision 19 in nourse (current is 23).

In older nourse it has this to say about it in 19:

5.6.3.  Backwards Compatibility

   Versions of SCEP prior to revision 3 do not support GetCACertChain or
   GetNextCACert.  Certificate Authorities written to these prior
   versions will not be able to process the message and may return an
   HTML error.

   To avoid this, clients should send the GetCACert message first.  If
   the returned certificate is self-signed or is signed by a Certificate
   Authority that is trusted by the client, then it is not necessary to
   send the GetCACertChain message and it should not be sent.

   An old CA in a two-deep hierarchy might still get this message from a
   client if the client did not trust either that CA or its issuer.

So GetCACert should be sufficient.

What version of AD are you seeing this as required?

I probably overstated that. It just seemed useful and [possibly] necessary based on limited testing that I did when discovering this bug. If you're familiar with the RFCs I will defer to your expertise. I suppose if the next release doesn't work despite having the message property back in then we'll know it was needed =-).

I'm not infallible so I appreciate any feedback you can provide. I checked sscep, another open source SCEP client, and it doesn't support GetCACertChain either.

I'm trying to dig up an AD 2012 server I can test against to see whether the current patch is sufficient or needs more work.

I'm capable of digging into source code but don't usually have the time. Therefore, I often take a product for what it provides. What I know is that I did try to get sscep to work for our interaction from RHEL/CentOS clients to the MS-CA but was unable to. Certmonger fit the bill. What the differences are, I'm not sure. Hopefully, this isn't one of the features that's needed to have things work.

I appreciate your efforts in trying to fix this. For now we've restricted our initial installation of certmonger to 0.78.4-11.

I'm trying to dig up an AD 2012 server I can test against to see whether the current patch is sufficient or needs more work.

I've also ended up with downgrading certmonger to 0.78.4-11 in order to be able to add the CA for a Windows 2012 R2 SCEP server. I also see the same issue with all the certmonger versions in RHEL8.

I'd be happy to help testing out patches, on both RHEL7 and 8.

I reproduced this against a 2012 R2 server and it requires a message for both GetCACaps and GetCACert.

Upstream PR https://pagure.io/certmonger/pull-request/152

This patch should apply cleanly with a RHEL-7 srpm.

This patch should apply cleanly with a RHEL-7 srpm.

Thanks for the patch!

I applied it for RHEL7 and can confirm that it builds cleanly and resolves the issues with adding a CA when the SCEP service is running on a Windows Server 2012 R2.

I applied it for RHEL7 and can confirm that it builds cleanly and resolves the issues with adding a CA when the SCEP service is running on a Windows Server 2012 R2.

WIth minor modifications to the patch, it builds and resolves the issue on RHEL8 as well. 2 x thanks.

Thanks for testing it.

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata