The most common Certificate profiles are provided by default. The SSL server profile is one of the most common ones, which you can see under the "Certificate Profiles" tab at the ee port: https:/</host>:<port>/ca/ee/ca
Once you click on the "Manual Server Certificate Enrollment" profile, you will see that this profile takes a PKCS$10 request, which many server application should have the capability to generate if you follow their installation procedure.

In general, out of security concern, most server administrators don't want the CA's administrators to have access to their server private keys, as the CA usually belongs to another organization or under a different administration, that's why you will normally not see in practice the CA administrator acting on those servers' behalf.

In your case, if you don't have such concern, the CA administrator could use tools such as certutil to generate the CSR in PKCS10, submit the request through the "Manual Server Certificate Enrollment" profile I mentioned above, import the cert into the db where the CSR was generated, and pkcs12 export to hand the keys/cert back to the server administrator.

You mentioned the Manual enrollment where keys are generated in the browser. Such default profiles are provided for user certs. The certificate requests are generated in CRMF rather than PKCS#10. You can craft your own certificate profile by using the right input plugins and policysets. For example, if you look in the manual one you can see that input.i1.class_id=keyGenInputImpl profiles key generation, and if you look in the ssl server one you can see the serverCertSet for ssl server cert. Combine them then you can have key generation in the browser and cert with ssl capability once approved.
You can learn about how to set up certificate profiles from the RHCS documentation:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html-single/Admin_Guide/index.html#Certificate_Profiles
Please keep in mind that the profile editing I described above was at a very high level. If you are going this route you need to think about taking in a different nickname for each enrollment because you are having the administrator generate the keys in his/her own browser, so all CSRs are sharing the same nss db. You can write your own plugin to handle that or follow strict procedure to delete right after pkcs12 export. In my view, this is not something I'd offer as a standard interface.

Christina

On 03/28/2014 08:36 AM, JACKSON, BOYD R wrote:

Hello everyone, does anyone on the list know where we can get answer for the questions below?

What’s the appropriate procedure(s) for generating SSL certificates on behalf of someone and/or only dogtag administrators generating the ssl certificate for users/clients?

How or can we edit the Certificate Profiles; For example, if we generate a certificate with private key archival like the Manual User Signing and Encryption Certificates Enrollment, we can do that as a caAdmin, then retrieve the private keys, and then save out a pkcs12 file that we could give to a client for importation into their browser without ever having someone other than a caAdmin use the dogtag server. Unfortunately, that profile is only generating a certificate for email. We need SSL. Then, how do we enable either a custom profile, or another profile that has the capabilities we would prefer?

Boyd Jackson

AT&T Government Solutions

Cell- 703-314-9173

Fax- 212-202-5261
_______________________________________________
Pki-users mailing list
Pki-users@redhat.com
https://www.redhat.com/mailman/listinfo/pki-users