Stand-alone PKI Subsystems

From Dogtag
Jump to: navigation, search

Stand-alone PKI Subsystems

Overview

Dogtag PKI subsystems such as a Data Recovery Managers (DRMs) and an Online Certificate Status Protocol (OCSP) Managers have always required the presence of a Certificate Authority (CA) to be part of a PKI deployment.

Recently, however, it has been determined that it would be beneficial to be able to allow some of these PKI subsystems (e. g. - DRM and OCSP) to be setup as stand-alone systems which do not include a CA in their PKI deployment.

It should be emphasized that these stand-alone PKI subsystems are not expected to communicate with any other PKI subsystems (with the exception of their clones).

Associated Bugs and Tickets

Use Cases

Case I: Stand-alone DRM

  • A PKI deployment should be able to setup a DRM without the need to have a CA.
  • This stand-alone DRM should not be expected to communicate with any other PKI subsystem (with the possible exception of any DRMs that have been cloned from this stand-alone DRM).
  • This stand-alone DRM should host its own security domain.
  • This stand-alone DRM will require five PKI subsystem certificates to be signed and issued by a single External CA:
    • Transport Certificate
    • Storage Certificate
    • SSL Server Certificate
    • Subsystem Certificate
    • Audit Log Signing Certificate
  • Additionally, for administration purposes, this DRM will require an Administration Certificate to be signed and issued by the same External CA that signed its other five certificates.
  • This stand-alone DRM should be able to be cloned.
  • Each DRM clone will be limited to use the master DRM security domain.

Case II: DRM Cloned from Stand-alone DRM

  • A PKI deployment should be able to clone a DRM from a fully configured stand-alone DRM.
  • This cloned DRM should not be expected to communicate with any other PKI subsystem other than the master stand-alone DRM from which it was cloned.
  • This cloned DRM must use the master stand-alone DRM as its security domain.
  • This cloned DRM will require one PKI subsystem certificate to be signed and issued by the same External CA that was utilized by the master stand-alone DRM:
    • SSL Server Certificate
NOTE:   For administration purposes, this cloned DRM will utilize the Administration Certificate that was signed and issued for the DRM master.

Case III: Stand-alone OCSP

  • A PKI deployment should be able to setup an OCSP without the need to have a CA.
  • This stand-alone OCSP should not be expected to communicate with any other PKI subsystem (with the possible exception of any OCSPs that have been cloned from this stand-alone OCSP).
  • This stand-alone OCSP should host its own security domain.
  • This stand-alone OCSP will require four PKI subsystem certificates to be signed and issued by a single External CA:
    • OCSP Signing Certificate
    • SSL Server Certificate
    • Subsystem Certificate
    • Audit Log Signing Certificate
  • Additionally, for administration purposes, this OCSP will require an Administration Certificate to be signed and issued by the same External CA that signed its other four certificates.
  • This stand-alone OCSP should be able to be cloned.
  • Each OCSP clone will be limited to use the master OCSP security domain.

Case IV: OCSP Cloned from Stand-alone OCSP

  • A PKI deployment should be able to clone an OCSP from a fully configured stand-alone OCSP.
  • This cloned OCSP should not be expected to communicate with any other PKI subsystem other than the master stand-alone OCSP from which it was cloned.
  • This cloned OCSP must use the master stand-alone OCSP as its security domain.
  • This cloned OCSP will require one PKI subsystem certificate to be signed and issued by the same External CA that was utilized by the master stand-alone OCSP:
    • SSL Server Certificate
NOTE:   For administration purposes, this cloned OCSP will utilize the Administration Certificate that was signed and issued for the OCSP master.

Operating System Platforms and Architectures

This design is initially targeted for the following platforms:

  • DRM [Dogtag 10.1]
    • 32-bit Fedora 20 [i686]
    • 64-bit Fedora 20 [x86_64]
  • OCSP [Dogtag 10.2]?
    • TBD

Design

This design will apply to the following PKI subsystems:

  • DRM
  • OCSP

Installation and configuration of a PKI stand-alone subsystem will consist of one of the following:

  • pkispawn (two pass installation and configuration utilizing the RESTEasy interface)
    • First invocation will create the following certificate requests for the specified PKI subsystems:
      • DRM - Transport Certificate Request, Storage Certificate Request, SSL Server Certificate Request, Subsystem Certificate Request, Audit Log Signing Request, and Administration Certificate Request
      • OCSP - OCSP Signing Certificate Request, SSL Server Certificate Request, Subsystem Certificate Request, Audit Log Signing Request, and Administration Certificate Request
    • All requests generated by the first invocation will be submitted to and signed by an External CA.
      • QUESTION:   Do we want to allow/support the ability for individual certificate requests to be signed by different External CA's?
      • ANSWER:   While it may be possible to manually setup all of the trusts, we would recommend that the same External CA be used for all certificate requests.
    • Second invocation will import the following certificates that have been signed by an External CA into the specified PKI subsystems:
      • DRM - Transport Certificate, Storage Certificate, SSL Server Certificate, Subsystem Certificate, Audit Log Signing Certificate, and Administration Certificate. Additionally, the External CA Certificate and its Chain will be imported and trusted.
      • OCSP - OCSP Signing Certificate, SSL Server Certificate, Subsystem Certificate, Audit Log Signing Certificate, and Administration Certificate. Additionally, the External CA Certificate and its Chain will be imported and trusted.
  • pkispawn (installation) + browser GUI (configuration)
    • all certificate requests and certificates will be requested/generated/installed during the browser GUI configuration

PKI stand-alone subsystems will consist of their own security domain (i. e. - they will not depend upon a CA being present as a part of their PKI deployment).

PKI stand-alone subsystems are not expected to communicate with any other PKI subsystem (with the notable exception of any master-clone communication).

PKI stand-alone subsystems will have the ability to be cloned with the imposed restriction that any clone of a stand-alone PKI subsystem must utilize the master stand-alone PKI subsystem as its security domain.

Implementation

Phases

Implementation of this feature will take place in the following phases:

  • Phase I:     Stand-alone DRM using 'pkispawn' RESTEasy Interface
  • Phase II:    Stand-alone DRM using 'pkispawn' + Browser GUI Legacy Interface
  • Phase III:   Stand-alone OCSP using 'pkispawn' RESTEasy Interface
  • Phase IV:   Stand-alone OCSP using 'pkispawn' + Browser GUI Legacy Interface

Changes to 'default.cfg'

For pkispawn, the default.cfg file will contain the following sections which must be overridden by a configuration file passed to pkispawn via the -f [file] command-line option: 

. . .
###############################################################################
##  KRA Configuration:                                                       ##
##                                                                           ##
##  Values in this section are common to KRA subsystems                      ##
##  including 'PKI KRAs', 'Cloned KRAs', and 'Stand-alone KRAs' and contain  ##
##  required information which MAY be overridden by users as necessary.      ##
##                                                                           ##
##      STAND-ALONE KRAs:  To specify a 'Stand-alone KRA', change the value  ##
##                         of 'pki_standalone' from 'False' to 'True', and   ##
##                         specify the various "pki_external" parameters     ##
##                         as appropriate.                                   ##
###############################################################################
[KRA]
. . .
pki_standalone=False
pki_external_admin_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.csr
pki_external_audit_signing_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.csr
pki_external_sslserver_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.csr
pki_external_storage_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_storage.csr
pki_external_subsystem_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.csr
pki_external_transport_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_transport.csr
pki_external_step_two=False
pki_external_ca_cert_chain_path=%(pki_instance_configuration_path)s/external_ca_chain.cert
pki_external_ca_cert_path=%(pki_instance_configuration_path)s/external_ca.cert
pki_external_admin_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.cert
pki_external_audit_signing_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.cert
pki_external_sslserver_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.cert
pki_external_storage_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_storage.cert
pki_external_subsystem_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.cert
pki_external_transport_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_transport.cert
. . .
###############################################################################
##  OCSP Configuration:                                                      ##
##                                                                           ##
##  Values in this section are common to OCSP subsystems                     ##
##  including 'PKI OCSPs', 'Cloned OCSPs', and 'Stand-alone OCSPs' and       ##
##  contain required information which MAY be overridden by users as         ##
##  necessary.                                                               ##
##                                                                           ##
##      STAND-ALONE OCSPs:  To specify a 'Stand-alone OCSP', change the      ##
##                          value of 'pki_standalone' from 'False' to        ##
##                          'True', and specify the various "pki_external"   ##
##                          parameters as appropriate.                       ##
##                                                                           ##
###############################################################################
[OCSP]
. . .
pki_standalone=False
pki_external_admin_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.csr
pki_external_audit_signing_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.csr
pki_external_signing_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_signing.csr
pki_external_sslserver_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.csr
pki_external_subsystem_csr_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.csr
pki_external_step_two=False
pki_external_ca_cert_chain_path=%(pki_instance_configuration_path)s/external_ca_chain.cert
pki_external_ca_cert_path=%(pki_instance_configuration_path)s/external_ca.cert
pki_external_admin_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.cert
pki_external_audit_signing_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.cert
pki_external_signing_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_signing.cert
pki_external_sslserver_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.cert
pki_external_subsystem_cert_path=%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.cert
. . .

Changes to 'acl.ldif' and 'db.ldif'

DRM

The following code needs to be added to the DRM acl.ldif file to provide the ability for a stand-alone DRM subsystems to support a security domain: 

. . .
resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" ||
group="Enterprise KRA Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml
. . .

Similarly, the following code needs to be added to the DRM db.ldif file to provide the ability for stand-alone DRM subsystems to support a security domain: 

. . .
dn: cn=Security Domain Administrators,ou=groups,{rootSuffix}
objectClass: top
objectClass: groupOfUniqueNames
cn: Security Domain Administrators
description: People who are the Security Domain administrators

dn: cn=Enterprise KRA Administrators,ou=groups,{rootSuffix}
objectClass: top
objectClass: groupOfUniqueNames
cn: Enterprise KRA Administrators
description: People who are the administrators for the security domain for KRA
. . .

OCSP

The following code needs to be added to the OCSP acl.ldif file to provide the ability for stand-alone OCSP subsystems to support a security domain: 

. . .
resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" ||
group="Enterprise OCSP Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml
. . .

Similarly, the following code needs to be added to the OCSP db.ldif file to provide the ability for stand-alone OCSP subsystems to support a security domain: 

. . .
dn: cn=Security Domain Administrators,ou=groups,{rootSuffix}
objectClass: top
objectClass: groupOfUniqueNames
cn: Security Domain Administrators
description: People who are the Security Domain administrators

dn: cn=Enterprise OCSP Administrators,ou=groups,{rootSuffix}
objectClass: top
objectClass: groupOfUniqueNames
cn: Enterprise OCSP Administrators
description: People who are the administrators for the security domain for OCSP
. . .

Changes to 'web.xml'

The following code needs to be added to the DRM/OCSP web.xml files whose availability will probably be controlled via a defined "slot" variable associated with stand-alone PKI subsystems: 


   <servlet>
      <servlet-name>  caGetDomainXML  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.GetDomainXML  </servlet-class>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caGetDomainXML </param-value> </init-param>
   </servlet>

   <servlet>
      <servlet-name>  caUpdateDomainXML  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.UpdateDomainXML  </servlet-class>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> true       </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caUpdateDomainXML </param-value> </init-param>
             <init-param><param-name>  interface   </param-name>
                         <param-value> agent          </param-value> </init-param>
             <init-param><param-name>  AuthMgr     </param-name>
                         <param-value> certUserDBAuthMgr </param-value> </init-param>
             <init-param><param-name>  AuthzMgr    </param-name>
                         <param-value> BasicAclAuthz </param-value> </init-param>
             <init-param><param-name>  resourceID  </param-name>
                         <param-value> certServer.securitydomain.domainxml </param-value> </init-param>
   </servlet>

 <servlet>
      <servlet-name>  caUpdateDomainXML-admin  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.UpdateDomainXML  </servlet-class>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caUpdateDomainXML </param-value> </init-param>
             <init-param><param-name>  interface   </param-name>
                         <param-value> admin          </param-value> </init-param>
             <init-param><param-name>  AuthMgr     </param-name>
                         <param-value> TokenAuth </param-value> </init-param>
             <init-param><param-name>  AuthzMgr    </param-name>
                         <param-value> BasicAclAuthz </param-value> </init-param>
             <init-param><param-name>  resourceID  </param-name>
                         <param-value> certServer.securitydomain.domainxml </param-value> </init-param>
   </servlet>

   <servlet>
      <servlet-name>  caSecurityDomainLogin  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.SecurityDomainLogin  </servlet-class>
            <init-param> <param-name>properties</param-name>
                         <param-value>/WEB-INF/velocity.properties</param-value> </init-param>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  AuthzMgr    </param-name>
                         <param-value> BasicAclAuthz </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caSecurityDomainLogin  </param-value> </init-param>
             <init-param><param-name>  resourceID  </param-name>
                         <param-value> certServer.ee.certificates </param-value> </init-param>
   </servlet>

   <servlet>
      <servlet-name>  caGetCookie  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.GetCookie  </servlet-class>
            <init-param> <param-name>properties</param-name>
                         <param-value>/WEB-INF/velocity.properties</param-value> </init-param>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  AuthzMgr    </param-name>
                         <param-value> BasicAclAuthz </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caGetCookie  </param-value> </init-param>
             <init-param><param-name>  AuthMgr     </param-name>
                         <param-value> passwdUserDBAuthMgr </param-value> </init-param>
             <init-param><param-name>  templatePath  </param-name>
                         <param-value> /admin/ca/sendCookie.template </param-value> </init-param>
             <init-param><param-name>  errorTemplatePath  </param-name>
                         <param-value> /admin/ca/securitydomainlogin.template </param-value> </init-param>
   </servlet>

   <servlet>
      <servlet-name>  caTokenAuthenticate  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.TokenAuthenticate  </servlet-class>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caTokenAuthenticate  </param-value> </init-param>
             <init-param><param-name>  interface   </param-name>
                         <param-value> ee          </param-value> </init-param>
   </servlet>

   <servlet>
      <servlet-name>  caTokenAuthenticate-admin  </servlet-name>
      <servlet-class> com.netscape.cms.servlet.csadmin.TokenAuthenticate  </servlet-class>
             <init-param><param-name>  GetClientCert  </param-name>
                         <param-value> false       </param-value> </init-param>
             <init-param><param-name>  authority   </param-name>
                         <param-value> ca          </param-value> </init-param>
             <init-param><param-name>  ID          </param-name>
                         <param-value> caTokenAuthenticate  </param-value> </init-param>
             <init-param><param-name>  interface   </param-name>
                         <param-value> admin          </param-value> </init-param>
   </servlet>

 <servlet-mapping>
      <servlet-name>  caGetDomainXML </servlet-name>
      <url-pattern>   /admin/ca/getDomainXML  </url-pattern>
   </servlet-mapping>

   <servlet-mapping>
      <servlet-name>  caUpdateDomainXML </servlet-name>
      <url-pattern>   /agent/ca/updateDomainXML  </url-pattern>
   </servlet-mapping>

   <servlet-mapping>
      <servlet-name>  caUpdateDomainXML-admin </servlet-name>
      <url-pattern>   /admin/ca/updateDomainXML  </url-pattern>
   </servlet-mapping>
   <servlet-mapping>
      <servlet-name>  caSecurityDomainLogin </servlet-name>
      <url-pattern>   /admin/ca/securityDomainLogin  </url-pattern>
   </servlet-mapping>

   <servlet-mapping>
      <servlet-name>  caGetCookie </servlet-name>
      <url-pattern>   /admin/ca/getCookie  </url-pattern>
   </servlet-mapping>

   <servlet-mapping>
      <servlet-name>  caTokenAuthenticate </servlet-name>
      <url-pattern>   /ee/ca/tokenAuthenticate  </url-pattern>
   </servlet-mapping>

   <servlet-mapping>
      <servlet-name>  caTokenAuthenticate-admin </servlet-name>
      <url-pattern>   /admin/ca/tokenAuthenticate  </url-pattern>
   </servlet-mapping>

   <security-constraint>
        <web-resource-collection>
            <web-resource-name>Security Domain Services</web-resource-name>
            <url-pattern>/rest/securityDomain/installToken</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

Source Code Changes

To expose the REST security domain servlets, the following code needs to be added to KeyRecoveryAuthorityApplication.java for DRM subsystems: 

IConfigStore cs = CMS.getConfigStore();
boolean standalone = cs.getBoolean("kra.standalone", false);
if (standalone) {
    classes.add(SecurityDomainService.class);
}

and to OCSPApplication.java for OCSP subsystems: 

IConfigStore cs = CMS.getConfigStore();
boolean standalone = cs.getBoolean("ocsp.standalone", false);
if (standalone) {
    classes.add(SecurityDomainService.class);
}

Some pkidaemon Python code will require changes to implement this feature.

Major configuration options and enablement

DRM

Master

An example of a first-pass default.cfg override file for a stand-alone DRM might look something like this: 

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[KRA]
pki_standalone=True

An example of a second-pass default.cfg override file for a stand-alone DRM might look something like this: 

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[KRA]
pki_standalone=True
pki_external_step_two=True

Each stand-alone 'DRM' instance will contain the following parameter in its CS.cfg file: 

kra.standalone=true
    NOTE:   kra.standalone will be set to false on non-standalone DRMs, and this parameter will not be present in legacy DRMs.

Clone

An example of a first-pass default.cfg override file for a cloned DRM of a stand-alone DRM might look something like this:

TBD

An example of a second-pass default.cfg override file for a cloned DRM of a stand-alone DRM might look something like this:

TBD

Each cloned DRM of a stand-alone 'DRM' instance will contain the following parameter in its CS.cfg file: 

kra.standalone=true
    NOTE:   kra.standalone will be set to false on non-standalone cloned DRMs, and this parameter will not be present in legacy cloned DRMs.

OCSP

Master

An example of a first-pass default.cfg override file for a stand-alone OCSP might look something like this: 

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[OCSP]
pki_standalone=True

An example of a second-pass default.cfg override file for a stand-alone OCSP might look something like this: 

[DEFAULT]
pki_admin_password=<password>
pki_client_database_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
[OCSP]
pki_standalone=True
pki_external_step_two=True

Each stand-alone 'OCSP' instance will contain the following parameter in its CS.cfg file: 

ocsp.standalone=true
    NOTE:   ocsp.standalone will be set to false on non-standalone OCSPs, and this parameter will not be present in legacy OCSPs.

Clone

An example of a first-pass default.cfg override file for a cloned OCSP of a stand-alone OCSP might look something like this:

TBD

An example of a second-pass default.cfg override file for a cloned OCSP of a stand-alone OCSP might look something like this:

TBD

Each cloned OCSP of a stand-alone 'OCSP' instance will contain the following parameter in its CS.cfg file: 

ocsp.standalone=true
    NOTE:   ocsp.standalone will be set to false on non-standalone cloned OCSPs, and this parameter will not be present in legacy cloned OCSPs.

Cloning

PKI stand-alone subsystems will have the ability to be cloned with the imposed restriction that any clone of a stand-alone PKI subsystem must utilize the master stand-alone PKI subsystem as its security domain.

Updates and Upgrades

Since this is a brand new feature, it should require no update/upgrade logic.

Tests

Case I: Stand-alone DRM

External CA Installation/Configuration

Create an "External CA" for testing purposes:

  • Sample default.cfg override file (e. g. - /tmp/pki/ca.cfg):
 [DEFAULT]
 pki_admin_password=<password>
 pki_client_pkcs12_password=<password>
 pki_ds_password=<password>
 pki_ajp_port=18009
 pki_http_port=18080
 pki_https_port=18443
 pki_instance_name=external-ca
 pki_security_domain_https_port=18443
 pki_tomcat_server_port=18005
  • Run pkispawn to create this instance:
 # script -c 'pkispawn -s CA -f /tmp/pki/ca.cfg -vvv'

Stand-alone DRM (Step 1) Installation/Configuration

Create a "Stand-alone DRM" (Step 1):

  • Sample default.cfg override file (e. g. - /tmp/pki/kra_pass_one.cfg):
 [DEFAULT]
 pki_admin_password=<password>
 pki_client_database_password=<password>
 pki_client_pkcs12_password=<password>
 pki_ds_password=<password>
 pki_instance_name=standalone-drm
 [KRA]
 pki_standalone=True
  • Run pkispawn to create this instance:
 # script -c 'pkispawn -s KRA -f /tmp/pki/kra_pass_one.cfg -vvv'
   . . .
   Please obtain the necessary certificates for this stand-alone KRA,
   and re-run the configuration for step two.
  • Verify that the certificate requests have been generated and stored in 'CS.cfg':
 # grep "\.certreq=" /etc/pki/standalone-drm/kra/CS.cfg
 kra.admin.certreq=MIICujCCAaICAQAwd . . .
 kra.audit_signing.certreq=MIICmjCCA . . .
 kra.sslserver.certreq=MIICmDCCAYACA . . .
 kra.storage.certreq=MIIClDCCAXwCAQA . . .
 kra.subsystem.certreq=MIICljCCAX4CA . . .
 kra.transport.certreq=MIICljCCAX4CA . . .
  • Verify that a value for "preop.cert.admin.dn" has been stored in 'CS.cfg':
 # grep "preop.cert.admin.dn=" /etc/pki/standalone-drm/kra/CS.cfg
 preop.cert.admin.dn=cn=PKI Administrator,e=kraadmin@example.com,o=example.com Security Domain
  • Verify that the certificates contain the following values for Step 1 in 'CS.cfg':
 # grep "\.cert=" /etc/pki/standalone-drm/kra/CS.cfg
 kra.admin.cert=...paste certificate here...
 kra.audit_signing.cert=...paste certificate here...
 kra.sslserver.cert=...paste certificate here...
 kra.storage.cert=...paste certificate here...
 kra.subsystem.cert=...paste certificate here...
 kra.transport.cert=...paste certificate here...
  • Verify that the certificate requests exist in 'CSR' files for convenience:
 # ls -1 /etc/pki/standalone-drm/*.csr
 kra_admin.csr
 kra_audit_signing.csr
 kra_sslserver.csr
 kra_storage.csr
 kra_subsystem.csr
 kra_transport.csr

Use of External CA for Certificate Creation

  • Submit each CSR to the appropriate Certificate Profile of the External CA configured above:
 Manual Administrator Certificate Enrollment
 * /etc/pki/standalone-drm/kra_admin.csr
 * Subject Name: cn=PKI Administrator,e=kraadmin@example.com,o=example.com Security Domain
 Manual Log Signing Certificate Enrollment
 * /etc/pki/standalone-drm/kra_audit_signing.csr
 Manual Server Certificate Enrollment
 * /etc/pki/standalone-drm/kra_sslserver.csr
 Manual Subsystem Certificate Enrollment
 * /etc/pki/standalone-drm/kra_subsystem.csr
 Manual Data Recovery Manager Storage Certificate Enrollment
 * /etc/pki/standalone-drm/kra_storage.csr
 Manual Data Recovery Manager Transport Certificate Enrollment
 * /etc/pki/standalone-drm/kra_transport.csr
  • Approve each CSR and obtain the following certificates from the External CA configured above and place them into the files identified below:
 CN=CA Signing Certificate,O=example.com Security Domain
 * /etc/pki/standalone-drm/external_ca.cert
 * /etc/pki/standalone-drm/external_ca_chain.cert
 CN=PKI Administrator,E=kraadmin@example.com,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_admin.cert
 CN=KRA Audit Signing Certificate,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_audit_signing.cert
 CN=standalone-drm.example.com,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_sslserver.cert
 CN=KRA Subsystem Certificate,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_subsystem.cert
 CN=DRM Storage Certificate,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_storage.cert
 CN=DRM Transport Certificate,O=example.com Security Domain
 * /etc/pki/standalone-drm/kra_transport.cert
  • Verify that the certificates exist in 'cert' files for use by Stand-alone DRM (Step 2):
 # ls -1 /etc/pki/standalone-drm/*.cert
 external_ca.cert
 external_ca_chain.cert
 kra_admin.cert
 kra_audit_signing.cert
 kra_sslserver.cert
 kra_storage.cert
 kra_subsystem.cert
 kra_transport.cert

Stand-alone DRM (Step 2) Installation/Configuration

Create a "Stand-alone DRM" (Step 2):

  • Sample default.cfg override file (e. g. - /tmp/pki/kra_pass_two.cfg):
 [DEFAULT]
 pki_admin_password=<password>
 pki_client_database_password=<password>
 pki_client_pkcs12_password=<password>
 pki_ds_password=<password>
 pki_instance_name=standalone-drm
 [KRA]
 pki_standalone=True
 pki_external_step_two=True
  • Run pkispawn to create this instance:
 # script -c 'pkispawn -s KRA -f /tmp/pki/kra_pass_two.cfg -vvv'
  • Verify that the certificates contain the following values for Step 2 in 'CS.cfg':
 # grep "\.cert=" /etc/pki/standalone-drm/kra/CS.cfg
 kra.admin.cert=MIID4DCCAsigAwIBAgIBF . . .
 kra.audit_signing.cert=MIIDcDCCAligA . . .
 kra.external_ca.cert=MIIDyjCCArKgAwI . . .
 kra.external_ca_chain.cert=MIID/QYJK . . .
 kra.sslserver.cert=MIIDvjCCAqagAwIBA . . .
 kra.storage.cert=MIIDsDCCApigAwIBAgI . . .
 kra.subsystem.cert=MIIDsjCCApqgAwIBA . . .
 kra.transport.cert=MIIDsjCCApqgAwIBA . . .

Dependencies

This design should require no new package or library dependencies.

Packages

This design will be contained within the existing packages, and therefore should require no new packages.

External Impact

TBD

History

ORIGINAL DESIGN DATE:   September 5, 2013

Proposed Solution:   When the initial patch was provided (as documented in PKI TRAC Ticket #667 - provide option for ca-less drm install), it was believed that no security domain would be required. Additionally, the initial patch attempted to provide a solution for the legacy GUI browser interface rather than the pkispawn RESTEasy interface.
Reason for Rejection:   Upon closer examination of the code, it was realized that in order to provide the ability for a stand-alone PKI component to perform cloning, a security domain would be required. Additionally, the order of the implementation phases as described in this ticket was revised such that the initial implementation would address the pkispawn RESTEasy interface rather than the legacy GUI browser interface.
Retrieved from "http://www.dogtagpki.org/index.php?title=Stand-alone_PKI_Subsystems&oldid=15816"