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_Sy... 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: