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:
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users