To allow automatic vetting of Sentry CA 3R1-3R4 certificate requests.
2 years ago
Originally Published: 2001-07-10
Article Number
000054237
Applies To
Sentry CA 3R1 to 3R4 ONLY
TechNote 0093
Issue
To allow automatic vetting of Sentry CA 3R1-3R4 certificate requests.
Resolution
Sentry CA can allow signing of certificates without administrator intervention (without putting requests into a request queue and then manually signing them). You must simply change the LDAP ACL rules that determine the access to the database by the enrollment server using the 'Modify LDAP ACL Rules' function, and then put the automatic vetting templates in place.

Note that you do not need to change the LDAP ACL rules as shown below if you are doing automatic vetting via the administration webserver. These rule changes allow the enrollment webserver to have access to the items required for automatic vetting of the certificate requests.

1. Determine the md5 of your admin and enrollment server. This can be found at the end of the LDAP ACL rules in the rule that allows writing to the request-queue:
        access to dn="dn=request_queue"
               by dn="md5=<admin-server-md5>" write
               by dn="md5=<enrollment-server-md5>" write

   (after installation, the first one is always the admin server, the second one is always the enrollment server).

If you want to limit which CA can be automatically vetted, you will also need the md5 for each CA that you want to do automatic signing for. This can be viewed by looking at each CA of interest using the 'View existing CA'  function. (If you want to allow automatic vetting for all CAs you do not need to find their md5s.)

2. To enable the enrollment server to auto-sign only for one specific CA, add the following 5 lines BEFORE the current ACL for pem_rsapriv (order matters within the LDAP rules):

   # the enrollment server needs to access the private key of a CA
   # in order to do automatic signing
   #
   access to dn="md5=<CA-md5>" attrs=pem_rsapriv
               by dn="md5=<admin-server-md5>" write
               by dn="md5=<enrollment-server-md5>" read

Notes:
- To enable the enrollment server to sign for several (but not all) CAs, simply set up one access rule as above, for each CA you wish to be able to do auto-signing for.

- To enable the enrollment server to sign for ANY CA, change the existing pem_rsapriv rule from:

   access to dn=".*" attrs=pem_rsapriv
       by dn="md5=<admin-server-md5>" write
       by dn=".*" none

    to:

    access to dn=".*" attrs=pem_rsapriv
        by dn="md5=<admin-server-md5>" write
        by dn="md5=<enrollment-server-md5>" read
        by dn=".*" none

3. Change the ACL for xuda_certificate from:

   access to filter="objectclass=xuda_certificate"
                by dn="md5=<admin-server-md5>" write
                by dn=".*" read

    to:

    access to filter="objectclass=xuda_certificate"
                 by dn="md5=<admin-server-md5>" write
                 by dn="md5=<enrollement-server-md5>" write
                 by dn=".*" read

    so that the enrollment server can write the certificate to the database.

4. Add the following ACL. (We suggest you insert it just after the xuda_certificate ACL above):

   access to filter="objectclass=xuda_org"
                by dn="md5=<admin-server-md5>" write
                by dn="md5=<enrollment-server-md5>" read

5. Set up the auto-signing pages.
To make these templates accessible from your enrollment webserver, put these templates into the enroll-server subdirectory where you installed Sentry CA.  To make these templates accessible from your administrative webserver, put these templates below the admin-server/ca/admin/ subdirectory.

   You may pick up a sample copy of the xuda templates from:

   MSIE Autovetting: autovet-msie.zip

   Netscape Autovetting templates: Please contact RSA Security Support

   PKCS10 Autovetting templates: Please contact RSA Security Support

Additional notes:
   - Sentry CA version 3.x does not use the same templates for automatic vetting as was used under Sentry CA 1.x and 2.x.
   - TTL (time to live) should be set to the number of days that you want the certificates to be valid for.
   - If you attempt to auto-vet using a CA for which the LDAP ACL rules forbid access to the private key from the enrollment server, you simply get a browser error such as 'Document contains no data'.
   - If using a Luna CA for automatic vetting, the P11Prompt variable in WebServer/conf/sentry.conf must be set to 1 (which causes the Pin to only be prompted for at webserver startup).
   - To allow auto-vetting of a LUNA based CA, you must ensure that:
          a) The server is set to "prompt for PIN at startup"
              (the value of P11Prompt in the sentry.conf file is 1).
          b) The correct slot and PIN were entered at startup time.
To allow automatic vetting of certificate request for Sentry CA 3.5, 3.6, 3.7, 4.0, please refer to Primus Solution "To allow automatic vetting of certificate request for Sentry CA 3.5 and later." for detailed instructions.
To allow automatic vetting of certificate request for the Sentry CA versions later than 4.0 and Keon CA 5.7, refer to Sentry/Keon CA Administrator's Guide, the "Automatic Vetting of Certificate Requests Submitted via the Enrollment Server" section in Chapter 3 for detailed instructions
 

Related Articles

Trending Articles

Don't see what you're looking for?