AD CA interaction not succeeding about scep HOT 2 CLOSED

Thanks for documenting this issue.

When I implemented the client, I only added support for the POST operation, which most modern SCEP servers should support. I'm surprised that the MS one does not.

In a POST request, the MESSAGE is in the request body, but in GET it has to be encoded as a URL parameter.

Early SCEP drafts performed all communications via "GET" messages,
including non-idempotent ones that should have been sent via "POST"
messages. This has caused problems because of the way that the
(supposedly) idempotent GET interacts with caches and proxies, and
because the extremely large GET requests created by encoding CMS
messages may be truncated in transit. These issues are typically not
visible when testing on a LAN, but crop up during deployment over
WANs. If the remote CA supports it, any of the CMS [3]-encoded SCEP
messages SHOULD be sent via HTTP POST instead of HTTP GET. This is
allowed for any SCEP message except GetCACert, GetNextCACert, or
GetCACaps, and avoids the need for base64- and URL-encoding that's
required for GET messaging. The client can verify that the CA
supports SCEP messages via POST by looking for the "POSTPKIOperation"
capability (See Section 3.4.2).
section [5.1] of the RFC draft https://tools.ietf.org/html/draft-gutmann-scep-02#section-5.1

I will try to add support for GET request messages for the client.

from scep.

Jesse closed this one, but there's bigger issues with NDES =)

from scep.