Nalin Dahyabhai wrote:
I think I'm getting closer to having certmonger (the provider of the ipa-getcert command) be useful enough to throw certificate enrollment requests at the IPA server, and I've got a couple of questions about how the server decides what it will issue and what it puts in the certificates that it issues.First, how we are we going to be expected to pass, to the server, information about the certificate we'd like it to issue? Until now, I've been storing the principal name in a subjectAltName value in an extensionRequest attribute in the signing request. I can actually put quite a bit of information in extensionRequests. It's not a lot of trouble to also provide that information along with the signing request (as 1.9.0 expects, at least for the Kerberos principal name), but if the server's going to be taking direction from the client on any of these things, it might be more future-proof if it could parse the request and validate its contents directly. This would make adding a requested dnsName subjectAltName possible without breaking any of the existing interfaces -- the client could request it, or not, or more than one value, and the server would pick and choose from everything that the client requested when deciding what to put into a certificate. The other question is about client authorization: have we set down the rules about which client identities are allowed to request what, and what they get?
There are 2 options. There is a rolegroup called certadmin. Members of this role are allowed to call cert-request, others will be rejected.
Alternatively you can specify which host(s) can request a certificate for a given service. Use the service-add-member command to add hosts that can request certs for it.
I ask because I think that we'll have to use the client host's identity (via creds obtained using its keytab) to handle the case where the connection to the CA doesn't become available until long after the admin's logged out, but when I try that now, requests submitted using the host's identity are being denied by the access control mechanisms.
Yes, the first access method is really designed for users/administrators. The second if you are binding as a host.
Anyone have some insight to share here?
A couple of tidbits:- In 1.9.0 we'll issue a certificate for any subject requested. dogtag has a fix that we will be able to use once it's released that will let us pull the CN from the request and use just that with the subject and use a fixed value for the rest. - The management framework doesn't do anything to the CSR right now, it literally just passes it onto the CA for processing.
- The whole ugly client IP thing has been ripped out post 1.9.0.- I still compare the hostname in the subject with the hostname of the service. This is unfortunately currently broken in python 2.4-based systems. - I'm not opposed to including more "stuff" into the CSR itself we just need to be sure the average admin who doesn't want to use certmonger can still make a request too. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-(
rob
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
