Your browser does not allow storing cookies. We recommend enabling them.

PreviousNextUp[Front page] [Index]

SCEP Service

The SCEP Service handles the server side of the Simple Certificate Enrollment Protocol (SCEP). The SCEP protocol is described in the Internet-Draft document draft-nourse-scep. SCEP uses HTTP as the transport protocol.

By default, the SCEP Service listens to the incoming SCEP messages on port 8080. The port can be modified via the Certifier Administration Service. See Section Editing the SCEP Service. The default enrollment URL for SCEP client is thus http://host:8080/scep/. These parameters have to be configured in the enrollment client which is typically a VPN client or a VPN gateway.

A prerequisite for SCEP enrollment is that the end entity has to have the appropriate CA certificate, which must have been verified using some offline method (fingerprint check). The verifications should be done to prevent man-in-the-middle attacks, in which someone is impersonating the CA. The CA certificate can be retrieved from the SCEP Service by an HTTP GET operation. In addition to the enrollment URL the end entity needs to know the name of the CA that identifies it within the SSH Tectia Certifier installation. This is needed since there may be several CAs providing SCEP within a single Certifier installation. The name that is used to identify CAs in SCEP implementation of SSH Tectia Certifier is the CA name given in the administration interface and is shown in the CA List page of the GUI (the subject name of the CA certificate is not used for this).

The initial end-entity authentication in SCEP is achieved either manually or by using shared secrets. When using a pre-shared secret scheme, the SSH Tectia Certifier administrator generates a pre-shared key (a password string) for an entity. The key is distributed to the entity in a secure way. When the certification request is generated, the shared secret is then used as a challenge password inside the request. The SCEP Service forwards the encrypted certification request to the Certifier Engine, which finds the policy bound to the pre-shared key and processes the request according to the policy.

When using manual authentication, the end entity calculates the MD5 fingerprint on the generated PKCS #10 certification request. When the Certifier Engine receives the request from the SCEP Service, it stores the request in the Database as a pending certification request. Later the end entity has to manually authenticate itself to the SSH Tectia Certifier operator with this fingerprint. The operator then compares it to the one found in the Database. If they match, the operator manually approves the certification request. The client can poll the issued certificate from the SCEP Service after this.

As the PKCS #7 request payload containing the PKCS #10 request is encrypted using the CA/RA's public key, no one else but the end entity and the CA/RA can know the fingerprint, and thus we know that the request is legitimate. (The end entity as we now know, has access to the private key, whose public components are inside the PKCS #10).

When the SCEP is performed between an end entity and an RA, the end entity needs also the RA certificate in addition to the CA certificate. So when the RA certificate is fetched by the end entity, also the CA certificate is sent in a PKCS #7 envelope to the end entity by the SCEP Service. This RA certificate can be used for both encryption and authentication in the enrollment.

PreviousNextUp[Front page] [Index]




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now