[Freeipa-devel] FreeIPA as external Puppet CA
I have been exploring the possibilities of using FreeIPA CA as an external Puppet CA with the requirement that Puppet will stay unmodified. Here are some notes: http://www.freeipa.org/page/IPA_as_external_Puppet_CA Thank you, Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0043 Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default
On 12/20/2012 06:49 AM, Simo Sorce wrote: On Thu, 2012-12-20 at 09:39 -0500, Ade Lee wrote: On Wed, 2012-12-19 at 21:35 -0500, Simo Sorce wrote: On Wed, 2012-12-19 at 22:41 +, JR Aquino wrote: On Dec 19, 2012, at 2:32 PM, Simo Sorce wrote: On Wed, 2012-12-19 at 20:52 +, JR Aquino wrote: Due to a limitation with 389 DS, the nsslapd-maxbersize cannot be set dynamically. This causes an issue during IPA PKI-CA Replica installs, when the master has a CRL that exceeds the default limit. The cainstance.py code attempts to set this value prior to performing the initial PKI-CA replication, however, since the value cannot be set dynamically, the installation fails. This patch works around the issue by adding the ldif to the original initialization values bootstrapped by the call to setup-ds.pl Why are we not simply restarting the instance after setting the value ? What's in database.ldif ? What produces it ? /usr/share/pki/ca/conf/database.ldif is part of the dogtag installation and it contains the following entry: dn: cn=config changetype: modify replace: nsslapd-maxbersize nsslapd-maxbersize: 209715200 It's purpose is to increase the limit for maxbersize from 2097152 to 209715200. If your CA is relatively recent, 209715200 should give you enough room to generate CRLs v1 with up to 9.4 millions entries. If you plan on having bigger CRLs, consider further increase of nsslapd-maxbersize. The ldif is inserted via the jars that are wrapped by pkisilent... So this leaves 3 options: #1 Add code to perform the ldap insert followed by a dirsrv restart into the cainstance.py code #2 Add recode the jar files from DogTag to require a dirsrv restart after the insert, but prior to the replication #3 Just initialize the dirsrv database with the correct value to begin with. 1 line fix #4 Ask 389 to allow maxbersize to be a dynamically initialized variable #3 Seemed the path of least resistance. I did take the time to code #1 and verify that it worked as well. I have a ticket open for #4 Alee hinted that the jar modifications for #2 might not be trivial... Method #3 is ok, but for master, where we have unified ds instances, you should look at doing ti as we do change other similar attributes in install/updates/10-config.update so that older installations are updated as well. If you do it only at install and the CRL grows later you'd get older server start choking because they have not been updated. Are you referring to masters which have been converted from non-unified DS to a single DS using an as-yet-to-be-written script? I was thinking of a current 3.1 setup with multiple replicas installed before this patch lands in Fedora. Old master (3.0) with split instances, new replicas (3.1) with unified instances. After a while CRL in master grows past limit. All replicas break because no update fixed them. The ldif change mentioned above is already performed as part of the dogtag install. For a freshly installed master, there is no large CRL to break the installation. In the replica scenario, this change is needed before we attempt replication because the large CRL breaks replication. In fact, if that value had not been set on the master, there would be no large CRL to cause replication problems. Understood, I am not asking for a huge change, just that the change is done in an update file and not just on a fresh install. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1033 renew CA subsystem certificates
On 07/16/2012 01:35 PM, Rob Crittenden wrote: Nalin Dahyabhai wrote: On Mon, Jul 16, 2012 at 09:23:24AM -0400, Rob Crittenden wrote: Use the new certmonger capability to be able to renew the dogtag subsystem certificates (audit, OCSP, etc). Are the copies of the certificates in the pki-ca CS.cfg file being updated elsewhere? Or is it not turning out to be a problem if they aren't? I didn't test validating OCSP signatures but the audit subsystem seemed fine (it complained wildly when I had the wrong trust in the NSS db). Andrew, do I need to update CS.cfg as well? Yes, you may need update CS.cfg too. Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/02/2011 03:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob Steps 1 to 3 should have an option to be performed only by CS admins with certificate client authentication, otherwise we will break rules of secure CS configuration including separation of roles. Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/05/09 11:34, Simo Sorce wrote: On Thu, 2009-11-05 at 11:28 -0800, Andrew Wnuk wrote: On 11/05/09 11:22, Simo Sorce wrote: On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: This is about right. What you're missing is storing the certificate in the service record. To do this we need to know what the target is. Nalin and I simply took two different approaches to sending this. We can easily support either method by making the principal an optional attribute and looking for it in the CSR if not provided (assuming I can get my head around PKCS#10 enough to grab attributes). Given we should prevent tricks from people the server side should really parse the CSR and validate it against the ACL IMO. Otherwise do we have any other part that checks that host foo.example.com is asking a certificate for itself and not for bar.example.com ? Simo. CSR is parsed and validated by CA. How does the CA know Who asked for a specific cert ? Simo. CA authenticates IPA and validates CSR, IPA authenticates and authorizes. Andrew. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/04/09 16:16, Nalin Dahyabhai wrote: On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: 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. That sounds reasonable. Is this new post-1.9.0? I can add members to various groups, but there's no service-add-member command yet. 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. That sounds good -- the default request subject is just 'CN=hostname' unless it's told different. - 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. If we're requiring that every certificate has an associated principal name, then ensuring it agrees with the hostname in the subject field makes a lot of sense. I'd kind of like to see both a dnsName and a Kerberos principal name added to the subjectAltName fields in the issued certificate, but that's as much because we can as anything else. - 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. NSS's certutil can trivially add dns and email subjectAltName (SAN) values and extendedKeyUsage (EKU) values. I don't see a flag for adding a Kerberos principal name. OpenSSL's req command doesn't do most of that by default, but the configuration file can be used to tell it to do any of that. It could be scripted, for sure. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-( Yeah, it took me a while to figure out that that was how we were supposed to pass it in. Passing entire CSR as a parameter to ipa command could avoided if XML-RPC framework would provide pre and post processing callbacks on the client side. Parameters could be used to describe CSR (instead of passing entire CSR), pre-processing callback could generate CSR based on provided description, then XML-RPC call could submit generated CSR and finally post-processing callback could properly place obtained certificate. Regards, Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
