[rs-commit] r548 - in /mod_scep/trunk: ChangeLog mod_scep.c
rs-commit at redwax.eu
rs-commit at redwax.eu
Fri Mar 13 11:35:52 CET 2026
Author: minfrin at redwax.eu
Date: Fri Mar 13 11:35:51 2026
New Revision: 548
Log:
Remove SHA1 from GetCACaps.
Update specification details to RFC8894.
Modified:
mod_scep/trunk/ChangeLog
mod_scep/trunk/mod_scep.c
Modified: mod_scep/trunk/ChangeLog
==============================================================================
--- mod_scep/trunk/ChangeLog (original)
+++ mod_scep/trunk/ChangeLog Fri Mar 13 11:35:51 2026
@@ -1,5 +1,7 @@
Changes with v1.0.0
+
+ *) Remove SHA1 from GetCACaps. [Graham Leggett]
*) Pass the challengePassword as a proof of possession in PkcsReq
messages. [Graham Leggett]
Modified: mod_scep/trunk/mod_scep.c
==============================================================================
--- mod_scep/trunk/mod_scep.c (original)
+++ mod_scep/trunk/mod_scep.c Fri Mar 13 11:35:51 2026
@@ -15,9 +15,21 @@
*/
/*
- * Implement a SCEP service.
+ * Implement an RFC 8894 SCEP service.
*
* Author: Graham Leggett
+ *
+ * We comply with the following:
+ *
+ * 2.9. Mandatory-to-Implement Functionality
+ *
+ * At a minimum, all SCEP implementations compliant with this
+ * specification MUST support GetCACaps (Section 3.5.1), GetCACert
+ * (Section 4.2), PKCSReq (Section 3.3.1) (and its associated response
+ * messages), communication of binary data via HTTP POST (Section 4.1),
+ * and the AES128-CBC [AES] and SHA-256 [SHA2] algorithms to secure
+ * pkiMessages (Section 3.2).
+ *
*
*/
#include <apr_lib.h>
@@ -1164,39 +1176,43 @@
}
/**
- * 5.2.1. GetCACert
- *
- * The OPERATION MUST be set to "GetCACert".
- *
- * The MESSAGE MAY be omitted, or it MAY be a string that represents the
- * certification authority issuer identifier. A CA Administrator
- * defined string allows for multiple CAs supported by one SCEP server.
- *
- * 5.2.1.1. GetCACert Response
- *
- * The response for GetCACert is different between the case where the CA
- * directly communicates with the requester during the enrollment, and
- * the case where a RA exists and the requester communicates with the RA
- * during the enrollment.
- *
- * 5.2.1.1.1. CA Certificate Only Response
- *
- * The response will have a Content-Type of "application/
- * x-x509-ca-cert".
- *
- * The body of this response consists of an X.509 CA certificate, as
- * defined in Section 4.1.1.1.
- * "Content-Type:application/x-x509-ca-cert\n\n"<binary X.509>
- *
- * 5.2.1.1.2. CA and RA Certificates Response
- *
- * The response will have a Content-Type of "application/
- * x-x509-ca-ra-cert".
- *
- * The body of this response consists of a degenerate certificates-only
- * PKCS#7 Signed-data (Section 3.3) containing both CA and RA
- * certificates, as defined in Section 4.1.1.2.
- * "Content-Type:application/x-x509-ca-ra-cert\n\n"<binary PKCS#7>
+ * 4.2. Get CA Certificate
+ *
+ * To get the CA certificate(s), the client sends a GetCACert message
+ * to the CA. The OPERATION MUST be set to "GetCACert". There is no
+ * request data associated with this message.
+ *
+ * 4.2.1. Get CA Certificate Response Message Format
+ *
+ * The response for GetCACert is different between the case where the
+ * CA directly communicates with the client during the enrolment and
+ * the case where an intermediate CA exists and the client
+ * communicates with this CA during the enrolment.
+ *
+ * 4.2.1.1. CA Certificate Response Message Format
+ *
+ * If the CA does not have any intermediate CA certificates, the
+ * response consists of a single X.509 CA certificate. The response
+ * will have a Content-Type of "application/x-x509-ca-cert".
+ *
+ * "Content-Type: application/x-x509-ca-cert"
+ *
+ * <binary X.509>
+ *
+ * 4.2.1.2. CA Certificate Chain Response Message Format
+ *
+ * If the CA has intermediate CA certificates, the response consists
+ * of a degenerate certificates-only CMS SignedData message
+ * (Section 3.4) containing the certificates, with the intermediate
+ * CA certificate(s) as the leaf certificate(s). The response will
+ * have a Content-Type of "application/x-x509-ca-ra-cert". Note that
+ * this designation is used for historical reasons due to its use in
+ * older versions of this specification -- no special meaning should
+ * be attached to the label.
+ *
+ * "Content-Type: application/x-x509-ca-ra-cert"
+ *
+ * <binary CMS>
*
*/
static int get_ca_cert(request_rec *r, scep_config_rec *conf,
@@ -1359,25 +1375,26 @@
}
/**
- * 5.2.6. GetNextCACert
- *
- * The OPERATION MUST be set to "GetNextCACert".
- *
- * The MESSAGE MAY be ommitted, or it MAY be a string that represents
- * the certification authority issuer identifier, if such has been set
- * by the CA Administrator.
- *
- * 5.2.6.1. GetNextCACert Response
- *
- * The response will have a Content-Type of "application/
- * x-x509-next-ca-cert".
- *
- * The body of this response consists of a SignedData PKCS#7 [RFC2315],
- * as defined in Section 4.6.1. (This is similar to the GetCert
- * response but does not include any of the attributes defined in
- * Section 3.1.1.)
- * "Content-Type:application/x-x509-next-ca-cert\n\n"
- * <binary PKCS#7>
+ * 4.7. Get Next Certificate Authority Certificate
+ *
+ * When a CA certificate is about to expire, clients need to
+ * retrieve the CA's next CA certificate (i.e., the rollover
+ * certificate). This is done via the GetNextCACert message.
+ * The OPERATION MUST be set to "GetNextCACert". There is no
+ * request data associated with this message.
+ *
+ * 4.7.1. Get Next CA Response Message Format
+ *
+ * The response consists of a SignedData CMS message, signed
+ * by the current CA signing key. Clients MUST validate the
+ * signature on the message before trusting any of its
+ * contents. The response will have a Content-Type of
+ * "application/x-x509-next-ca-cert".
+ *
+ * "Content-Type: application/x-x509-next-ca-cert"
+ *
+ * <binary CMS>
+ *
*/
static int get_next_ca_cert(request_rec *r, scep_config_rec *conf,
const char *message)
@@ -1539,6 +1556,13 @@
}
/**
+ * 3.5.1. GetCACaps HTTP Message Format
+ *
+ * This message requests capabilities from a CA, with the format as
+ * described in Section 4.1:
+ *
+ * "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF
+ *
* 3.5.2. CA Capabilities Response Format
*
*
@@ -1559,8 +1583,6 @@
* | | |
* | "Renewal" | CA supports the Renewal CA operation. |
* | | |
- * | "SHA-1" | CA supports the SHA-1 hashing algorithm. |
- * | | |
* | "SHA-256" | CA supports the SHA-256 hashing algorithm. |
* | | |
* | "SHA-512" | CA supports the SHA-512 hashing algorithm. |
@@ -1586,7 +1608,6 @@
"%s"
"POSTPKIOperation\n"
"Renewal\n"
- "SHA-1\n"
"SHA-256\n"
"SHA-512\n"
"SCEPStandard\n",
@@ -1926,7 +1947,19 @@
}
/**
- * MessageType: PKCSReq
+ * 3.3.1. PKCSReq/RenewalReq
+ *
+ * The messageData for this type consists of a PKCS #10
+ * Certificate Request. The certificate request MUST
+ * contain at least the following items:
+ *
+ * The subject Distinguished Name.
+ * The subject public key.
+ * For a PKCSReq, if authorisation based on a shared secret
+ * is being used, a challengePassword attribute.
+ *
+ * In addition, the message must contain the
+ * authenticatedAttributes specified in Section 3.2.1.
*/
static int scep_messagetype_pkcsreq(request_rec *r, X509_REQ *req, X509 *xpop, scep_t *scep)
{
@@ -2204,7 +2237,17 @@
}
/**
- * MessageType: RenewalReq
+ * 3.3.1. PKCSReq/RenewalReq
+ *
+ * The messageData for this type consists of a PKCS #10
+ * Certificate Request. The certificate request MUST
+ * contain at least the following items:
+ *
+ * The subject Distinguished Name.
+ * The subject public key.
+ *
+ * In addition, the message must contain the
+ * authenticatedAttributes specified in Section 3.2.1.
*/
static int scep_messagetype_renewalreq(request_rec *r, X509_REQ *req, X509 *xpop, scep_t *scep)
{
@@ -2465,7 +2508,36 @@
}
/**
- * MessageType: CertPoll
+ * 3.3.3. CertPoll (GetCertInitial)
+ *
+ * This message is used for certificate polling. For unknown
+ * reasons, it was referred to as "GetCertInitial" in earlier
+ * draft versions of this specification. The messageData for
+ * this type consists of an IssuerAndSubject:
+ *
+ * issuerAndSubject ::= SEQUENCE {
+ * issuer Name,
+ * subject Name
+ * }
+ *
+ * The issuer is set to the subjectName of the CA (in other
+ * words, the intended issuerName of the certificate that's
+ * being requested). The subject is set to the subjectName
+ * used when requesting the certificate.
+ *
+ * Note that both of these fields are redundant; the CA is
+ * identified by the recipientInfo in the pkcsPKIEnvelope
+ * (or in most cases, simply by the server that the message
+ * is being sent to), and the client/transaction being
+ * polled is identified by the transactionID. Both of these
+ * fields can be processed by the CA without going through
+ * the cryptographically expensive process of unwrapping and
+ * processing the issuerAndSubject. For this reason,
+ * implementations SHOULD assume that the polling operation
+ * will be controlled by the recipientInfo and transactionID
+ * rather than the contents of the messageData. In addition,
+ * the message must contain the authenticatedAttributes
+ * specified in Section 3.2.1.
*/
static int scep_messagetype_certpoll(request_rec *r,
PKCS7_ISSUER_AND_SUBJECT *ias, scep_t *scep)
@@ -2597,7 +2669,23 @@
}
/**
- * MessageType: GetCert
+ * 3.3.4. GetCert and GetCRL
+ *
+ * The messageData for these types consist of an
+ * IssuerAndSerialNumber, as defined in CMS, that uniquely
+ * identifies the certificate being requested, either the
+ * certificate itself for GetCert or its revocation status
+ * via a CRL for GetCRL. In addition, the message must
+ * contain the authenticatedAttributes specified in Section
+ * 3.2.1.
+ *
+ * These message types, while included here for completeness,
+ * apply unnecessary cryptography and messaging overhead to
+ * the simple task of transferring a certificate or CRL
+ * (see Section 7.8). Implementations SHOULD prefer HTTP
+ * certificate-store access [RFC4387] or LDAP over the use
+ * of these messages.
+ *
*/
static int scep_messagetype_getcert(request_rec *r,
PKCS7_ISSUER_AND_SERIAL *ias, scep_t *scep)
@@ -2708,14 +2796,27 @@
}
/**
- * MessageType: GetCRL
- *
- * The draft of the SCEP protocol expiring March 10, 2012 says the following:
- *
- * "The server SHOULD NOT support the GetCRL method..."
- *
- * If configured, we redirect the client to the real CRL distribution point
- * for this CA, otherwise we reject with a Bad Request.
+ * 3.3.4. GetCert and GetCRL
+ *
+ * The messageData for these types consist of an
+ * IssuerAndSerialNumber, as defined in CMS, that uniquely
+ * identifies the certificate being requested, either the
+ * certificate itself for GetCert or its revocation status
+ * via a CRL for GetCRL. In addition, the message must
+ * contain the authenticatedAttributes specified in Section
+ * 3.2.1.
+ *
+ * These message types, while included here for completeness,
+ * apply unnecessary cryptography and messaging overhead to
+ * the simple task of transferring a certificate or CRL
+ * (see Section 7.8). Implementations SHOULD prefer HTTP
+ * certificate-store access [RFC4387] or LDAP over the use
+ * of these messages.
+ *
+ *
+ * If configured, we redirect the client to the real CRL
+ * distribution point for this CA, otherwise we reject with
+ * a Bad Request.
*/
static int scep_messagetype_getcrl(request_rec *r, scep_t *scep)
{
More information about the rs-commit
mailing list