Re: [Freeipa-devel] [DRAFT] Release notes FreeIPA 4.5.0
On Wed, Mar 15, 2017 at 09:13:35AM +0100, Martin Basti wrote: > > > On 15.03.2017 00:49, Fraser Tweedale wrote: > > On Tue, Mar 14, 2017 at 01:51:19PM +0100, Martin Basti wrote: > >> Hello, > >> > >> DRAFT for FreeIPA 4.5.0 release notes is ready > >> http://www.freeipa.org/page/Releases/4.5.0 > >> > >> Please update/let me know what is missing, what is extra. > >> > >> > >> Martin^2 > >> > > I think we should add https://pagure.io/freeipa/issue/2614 to the > > `Enhancements' section. There is no design page for it but it was a > > big effort and it gives the deployer complete control over the IPA > > CA subject DN (previously this was very restricted). > > > > Thanks, > > Fraser > > Can you suggest what to write to release notes (preferably in copy paste > form) > > thank you :) > Here you go: == Fully customisable CA name == The CA subject name is now fully customisable, and is no longer required to be related to the certificate subject base. The *ipa-server-install* and *ipa-ca-install* commands learned the *--ca-subject* and *--subject-base* options for configuring these values. https://pagure.io/freeipa/issue/2614 Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DRAFT] Release notes FreeIPA 4.5.0
On Tue, Mar 14, 2017 at 01:51:19PM +0100, Martin Basti wrote: > Hello, > > DRAFT for FreeIPA 4.5.0 release notes is ready > http://www.freeipa.org/page/Releases/4.5.0 > > Please update/let me know what is missing, what is extra. > > > Martin^2 > I think we should add https://pagure.io/freeipa/issue/2614 to the `Enhancements' section. There is no design page for it but it was a big effort and it gives the deployer complete control over the IPA CA subject DN (previously this was very restricted). Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA and wildcard certificates
On Wed, Feb 22, 2017 at 10:17:32AM +0100, Martin Kosek wrote: > On 02/20/2017 06:03 AM, Fraser Tweedale wrote: > > On Fri, Feb 10, 2017 at 11:48:39AM +0100, Martin Kosek wrote: > >> On 02/10/2017 10:37 AM, Fraser Tweedale wrote: > >>> On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote: > >>>> On 02/09/2017 10:44 PM, Fraser Tweedale wrote: > >>>>> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote: > >>>>>> On 02/09/2017 02:12 AM, Fraser Tweedale wrote: > >>>>>>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote: > >>>>>>>> On ke, 08 helmi 2017, Martin Kosek wrote: > >>>>>>>>> Hi Fraser and the list, > >>>>>>>>> > >>>>>>>>> I recently was in a conversation about integrating OpenShift with > >>>>>>>>> FreeIPA. One > >>>>>>>>> of the gaps was around generating a wildcard certificate by FreeIPA > >>>>>>>>> that will > >>>>>>>>> be used in the default OpenShift router for applications that do > >>>>>>>>> not deploy own > >>>>>>>>> certificates [1]. > >>>>>>>>> > >>>>>>>>> Is there any way that FreeIPA can generate it? I was thinking that > >>>>>>>>> uploading > >>>>>>>>> some custom certificate profile in FreeIPA may let us get such > >>>>>>>>> certificate... > >>>>>>>>> Or is the the only way we can add it by adding a new RFE in > >>>>>>>>> FreeIPA, tracked in > >>>>>>>>> [2]? > >>>>>>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard > >>>>>>>> certificates to be issued: > >>>>>>>> > >>>>>>>> - we ensure subject 'cn' of the certificate matches a Kerberos > >>>>>>>> principal > >>>>>>>> specified in the request > >>>>>>>> > >>>>>>>> - we validate that host object exists in IPA when the Kerberos > >>>>>>>> principal is host/... > >>>>>>>> > >>>>>>>> We could lift off these two limitations for 'cn=*,$suffix' but there > >>>>>>>> is > >>>>>>>> still a need to apply proper ACLs when issuing the cert -- e.g. some > >>>>>>>> object has to be used for performing access rights check. The > >>>>>>>> wildcard > >>>>>>>> certificate does not need to be stored anywhere in the tree, but a > >>>>>>>> check still needs to be done. > >>>>>>>> > >>>>>>>> For example, for Kerberos PKINIT certificate which is issued to KDC > >>>>>>>> we > >>>>>>>> don't store public certificate in LDAP either but we do two checks: > >>>>>>>> - a special KDC certificate profile is used to issue the cert > >>>>>>>> - a special hostname check is done so that only IPA masters are able > >>>>>>>> to > >>>>>>>> request this certificate > >>>>>>>> > >>>>>>>> For the wildcard certificate I think we could have following: > >>>>>>>> - use a separate profile for the wildcard, associated with a sub-CA > >>>>>>>> - hardcode CN default in the profile to always be 'CN=*, > >>>>>>>> O=$SUB_CA_SUBJECT' so that > >>>>>>>> actual certificate ignores requested CN. > >>>>>>>> - a special check to be done so that only wildcard-based subject > >>>>>>>> alternative names can be added to a wildcard certificate request > >>>>>>>> - all Kerberos principal / hostname checks are skipped. > >>>>>>>> - actual ACL check is done by CA ACL. > >>>>>>>> > >>>>>>> Issuing wildcard certs is a deprecated practice[1]. I am not > >>>>>>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in > >>>>>>> general) but I'd like to have a
Re: [Freeipa-devel] Requiring simultaneous authentication to Linux resources
On Wed, Feb 22, 2017 at 10:00:04AM -0500, Simo Sorce wrote: > On Wed, 2017-02-22 at 10:59 +, Oucema Bellagha wrote: > > I want to figure out a solution which allow user"a" to authenticate to > > a host only when user"b" is accessing the host for security reasons. > > > > > > Easy explanation: authenticate to hostx needs (user a + user b) > > > > > > I'm brainstorming some ideas using Yubikey or ssh-keys.. Is there any > > application which allow us to access a host only when 2 users are > > present cause putty doesn't have this feature which can be a step to > > solve this problem .. > > > > > > Or in applying some specified rules in IPA itself ? > > As explained, there is no such concept in Unix/Linux to start with, but > maybe you mean that you want to check credentials of 2 different users > to allow privileged login, like root login ? > If this is the use case, it could be an interesting application for clevis. > Or is this something else ? > > It'd be nice if you can describe precisely what actions and results you > expect to see. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] MD5 certificate fingerprints removal
On Wed, Feb 22, 2017 at 01:41:22PM +0100, Tomas Krizek wrote: > On 02/22/2017 12:28 AM, Fraser Tweedale wrote: > > On Tue, Feb 21, 2017 at 05:23:07PM +0100, Standa Laznicka wrote: > >> On 02/21/2017 04:24 PM, Tomas Krizek wrote: > >>> On 02/21/2017 03:23 PM, Rob Crittenden wrote: > >>>> Standa Laznicka wrote: > >>>>> Hello, > >>>>> > >>>>> Since we're trying to make FreeIPA work in FIPS we got to the point > >>>>> where we need to do something with MD5 fingerprints in the cert plugin. > >>>>> Eventually we came to a realization that it'd be best to get rid of them > >>>>> as a whole. These are counted by the framework and are not stored > >>>>> anywhere. Note that alongside with these fingerprints SHA1 fingerprints > >>>>> are also counted and those are there to stay. > >>>>> > >>>>> The question for this ML is, then - is it OK to remove these or would > >>>>> you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a > >>>>> grandpa and I think it should go. > >>>> I based the values displayed on what certutil displayed at the time (7 > >>>> years ago). I don't know that anyone uses these fingerprints. The > >>>> OpenSSL equivalent doesn't include them by default. > >>>> > >>>> You may be able to deprecate fingerprints altogether. > >>>> > >>>> rob > >>> I think it's useful to display the certificate's fingerprint. I'm in > >>> favor of removing md5 and adding sha256 instead. > >>> > >> Rob, thank you for sharing the information of where the cert fingerprints > >> are originated! `certutil` shipped with nss-3.27.0-1.3 currently displays > >> SHA-256 and SHA1 fingerprints for certificates so I propose going that way > >> too. > >> > > IMO we should remove MD5 and SHA-1, and add SHA-256. But we should > > also make no API stability guarantee w.r.t. the fingerprint > > attributes, i.e. to allow us to move to newer digests in future (and > > remove broken/no-longer-secure ones). We should advise that if a > > customer has a hard requirement on a particular digest that they > > should compute it themselves from the certificate. > > > > Cheers, > > Fraser > What is the motivation to remove SHA-1? Are there any attacks besides > theoretical ones on SHA-1? > > Do other libraries already deprecate SHA-1? > Come to think of it, I was thinking about SHA-1 signatures (which are completely forbidden in the public PKI nowadays). But for fingerprints it is not so bad (for now). Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote: > On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: > > Hi, > > > > related to the Certificate Identity Mapping feature, a new CLI will be > > needed to find all the users matching a given certificate. > > > > I propose to provide this as: > > > > ipa certmaptest --certificate > > --- > > 2 users matched > > --- > > Matched user login: test1 > > Matched user login: test2 > > > > Number of entries returned 2 > > > > > > > > Please provide any comments, suggestions on the CLI or the output. > > Thanks, > > Flo. > > > > Thanks Flo for sharing it. > > I don't like the command name. It is not self explanatory. It says it is > testing something, it is not clear what and the actual result is users who > match the map configuration or have the cert in their user's entry. > > Better would be: > $ ipa certmap-match --certificate > How about `ipa certmap-find-user ...'? Doesn't get more obvious than that, IMO. > > Pasting user story to give context if somebody is not familiar with it: > """ > As a Security Officer, I want to present IdM Server with an Employee Smart > Card certificate and list all Employees with a matching role account, so > that I can validate the configuration is correct > > Note: In FreeIPA 4.4, user-find --certificate can already find users linked > with a certificate blob > > Acceptance criteria: > * I can perform the administrative task both via IdM Web UI and CLI > * When asking IdM for the information, I should always receive the same list > that would be matched in client authentication workflows (by SSSD) > * The list of users should include both users linked via standard > certificate blob and other generically mapped users > """ > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] MD5 certificate fingerprints removal
On Tue, Feb 21, 2017 at 05:23:07PM +0100, Standa Laznicka wrote: > On 02/21/2017 04:24 PM, Tomas Krizek wrote: > > On 02/21/2017 03:23 PM, Rob Crittenden wrote: > > > Standa Laznicka wrote: > > > > Hello, > > > > > > > > Since we're trying to make FreeIPA work in FIPS we got to the point > > > > where we need to do something with MD5 fingerprints in the cert plugin. > > > > Eventually we came to a realization that it'd be best to get rid of them > > > > as a whole. These are counted by the framework and are not stored > > > > anywhere. Note that alongside with these fingerprints SHA1 fingerprints > > > > are also counted and those are there to stay. > > > > > > > > The question for this ML is, then - is it OK to remove these or would > > > > you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a > > > > grandpa and I think it should go. > > > I based the values displayed on what certutil displayed at the time (7 > > > years ago). I don't know that anyone uses these fingerprints. The > > > OpenSSL equivalent doesn't include them by default. > > > > > > You may be able to deprecate fingerprints altogether. > > > > > > rob > > I think it's useful to display the certificate's fingerprint. I'm in > > favor of removing md5 and adding sha256 instead. > > > Rob, thank you for sharing the information of where the cert fingerprints > are originated! `certutil` shipped with nss-3.27.0-1.3 currently displays > SHA-256 and SHA1 fingerprints for certificates so I propose going that way > too. > IMO we should remove MD5 and SHA-1, and add SHA-256. But we should also make no API stability guarantee w.r.t. the fingerprint attributes, i.e. to allow us to move to newer digests in future (and remove broken/no-longer-secure ones). We should advise that if a customer has a hard requirement on a particular digest that they should compute it themselves from the certificate. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA and wildcard certificates
On Fri, Feb 10, 2017 at 11:48:39AM +0100, Martin Kosek wrote: > On 02/10/2017 10:37 AM, Fraser Tweedale wrote: > > On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote: > >> On 02/09/2017 10:44 PM, Fraser Tweedale wrote: > >>> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote: > >>>> On 02/09/2017 02:12 AM, Fraser Tweedale wrote: > >>>>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote: > >>>>>> On ke, 08 helmi 2017, Martin Kosek wrote: > >>>>>>> Hi Fraser and the list, > >>>>>>> > >>>>>>> I recently was in a conversation about integrating OpenShift with > >>>>>>> FreeIPA. One > >>>>>>> of the gaps was around generating a wildcard certificate by FreeIPA > >>>>>>> that will > >>>>>>> be used in the default OpenShift router for applications that do not > >>>>>>> deploy own > >>>>>>> certificates [1]. > >>>>>>> > >>>>>>> Is there any way that FreeIPA can generate it? I was thinking that > >>>>>>> uploading > >>>>>>> some custom certificate profile in FreeIPA may let us get such > >>>>>>> certificate... > >>>>>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, > >>>>>>> tracked in > >>>>>>> [2]? > >>>>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard > >>>>>> certificates to be issued: > >>>>>> > >>>>>> - we ensure subject 'cn' of the certificate matches a Kerberos > >>>>>> principal > >>>>>> specified in the request > >>>>>> > >>>>>> - we validate that host object exists in IPA when the Kerberos > >>>>>> principal is host/... > >>>>>> > >>>>>> We could lift off these two limitations for 'cn=*,$suffix' but there is > >>>>>> still a need to apply proper ACLs when issuing the cert -- e.g. some > >>>>>> object has to be used for performing access rights check. The wildcard > >>>>>> certificate does not need to be stored anywhere in the tree, but a > >>>>>> check still needs to be done. > >>>>>> > >>>>>> For example, for Kerberos PKINIT certificate which is issued to KDC we > >>>>>> don't store public certificate in LDAP either but we do two checks: > >>>>>> - a special KDC certificate profile is used to issue the cert > >>>>>> - a special hostname check is done so that only IPA masters are able to > >>>>>> request this certificate > >>>>>> > >>>>>> For the wildcard certificate I think we could have following: > >>>>>> - use a separate profile for the wildcard, associated with a sub-CA > >>>>>> - hardcode CN default in the profile to always be 'CN=*, > >>>>>> O=$SUB_CA_SUBJECT' so that > >>>>>> actual certificate ignores requested CN. > >>>>>> - a special check to be done so that only wildcard-based subject > >>>>>> alternative names can be added to a wildcard certificate request > >>>>>> - all Kerberos principal / hostname checks are skipped. > >>>>>> - actual ACL check is done by CA ACL. > >>>>>> > >>>>> Issuing wildcard certs is a deprecated practice[1]. I am not > >>>>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in > >>>>> general) but I'd like to have a discussion with them about how > >>>>> they're currently dealing with certs and whether a different > >>>>> direction other than wildcard certs is feasible. Martin, who should > >>>>> I reach out to? Feel free to copy them into this discussion. > >>>> > >>>> Right now, I am talking to a Solution Architect, i.e. someone who is > >>>> building > >>>> GAed solutions, not developers. This is not something we would change > >>>> short-term anyway, this is how current OpenShift v2 or v3 behaves, > >>>> despite the RFC. > >>>> > >>>> While I understand why having certificate *.lab.e
Re: [Freeipa-devel] FreeIPA and wildcard certificates
On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote: > On 02/09/2017 10:44 PM, Fraser Tweedale wrote: > > On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote: > >> On 02/09/2017 02:12 AM, Fraser Tweedale wrote: > >>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote: > >>>> On ke, 08 helmi 2017, Martin Kosek wrote: > >>>>> Hi Fraser and the list, > >>>>> > >>>>> I recently was in a conversation about integrating OpenShift with > >>>>> FreeIPA. One > >>>>> of the gaps was around generating a wildcard certificate by FreeIPA > >>>>> that will > >>>>> be used in the default OpenShift router for applications that do not > >>>>> deploy own > >>>>> certificates [1]. > >>>>> > >>>>> Is there any way that FreeIPA can generate it? I was thinking that > >>>>> uploading > >>>>> some custom certificate profile in FreeIPA may let us get such > >>>>> certificate... > >>>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, > >>>>> tracked in > >>>>> [2]? > >>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard > >>>> certificates to be issued: > >>>> > >>>> - we ensure subject 'cn' of the certificate matches a Kerberos principal > >>>> specified in the request > >>>> > >>>> - we validate that host object exists in IPA when the Kerberos > >>>> principal is host/... > >>>> > >>>> We could lift off these two limitations for 'cn=*,$suffix' but there is > >>>> still a need to apply proper ACLs when issuing the cert -- e.g. some > >>>> object has to be used for performing access rights check. The wildcard > >>>> certificate does not need to be stored anywhere in the tree, but a > >>>> check still needs to be done. > >>>> > >>>> For example, for Kerberos PKINIT certificate which is issued to KDC we > >>>> don't store public certificate in LDAP either but we do two checks: > >>>> - a special KDC certificate profile is used to issue the cert > >>>> - a special hostname check is done so that only IPA masters are able to > >>>> request this certificate > >>>> > >>>> For the wildcard certificate I think we could have following: > >>>> - use a separate profile for the wildcard, associated with a sub-CA > >>>> - hardcode CN default in the profile to always be 'CN=*, > >>>> O=$SUB_CA_SUBJECT' so that > >>>> actual certificate ignores requested CN. > >>>> - a special check to be done so that only wildcard-based subject > >>>> alternative names can be added to a wildcard certificate request > >>>> - all Kerberos principal / hostname checks are skipped. > >>>> - actual ACL check is done by CA ACL. > >>>> > >>> Issuing wildcard certs is a deprecated practice[1]. I am not > >>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in > >>> general) but I'd like to have a discussion with them about how > >>> they're currently dealing with certs and whether a different > >>> direction other than wildcard certs is feasible. Martin, who should > >>> I reach out to? Feel free to copy them into this discussion. > >> > >> Right now, I am talking to a Solution Architect, i.e. someone who is > >> building > >> GAed solutions, not developers. This is not something we would change > >> short-term anyway, this is how current OpenShift v2 or v3 behaves, despite > >> the RFC. > >> > >> While I understand why having certificate *.lab.example.com and using it > >> for my > >> lab machines is a bad idea and increases the attack vector, I do not see it > >> that way for OpenShift. There, applications get URL like > >> ".myopenshift.test" and all is routed by one entity, the OpenShift > >> broker. So the key.cert is on one location, just serving different names > >> that > >> are provisioned with OpenShift. > >> > >> I can understand that issuing a new certificate for every application > >> provisioned by OpenShift and then renewing it complicates the design > >> significantly. I am trying to be c
Re: [Freeipa-devel] FreeIPA and wildcard certificates
On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote: > On 02/09/2017 02:12 AM, Fraser Tweedale wrote: > > On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote: > >> On ke, 08 helmi 2017, Martin Kosek wrote: > >>> Hi Fraser and the list, > >>> > >>> I recently was in a conversation about integrating OpenShift with > >>> FreeIPA. One > >>> of the gaps was around generating a wildcard certificate by FreeIPA that > >>> will > >>> be used in the default OpenShift router for applications that do not > >>> deploy own > >>> certificates [1]. > >>> > >>> Is there any way that FreeIPA can generate it? I was thinking that > >>> uploading > >>> some custom certificate profile in FreeIPA may let us get such > >>> certificate... > >>> Or is the the only way we can add it by adding a new RFE in FreeIPA, > >>> tracked in > >>> [2]? > >> Yes, we need a new RFE. There are checks in IPA that prevent wildcard > >> certificates to be issued: > >> > >> - we ensure subject 'cn' of the certificate matches a Kerberos principal > >> specified in the request > >> > >> - we validate that host object exists in IPA when the Kerberos > >> principal is host/... > >> > >> We could lift off these two limitations for 'cn=*,$suffix' but there is > >> still a need to apply proper ACLs when issuing the cert -- e.g. some > >> object has to be used for performing access rights check. The wildcard > >> certificate does not need to be stored anywhere in the tree, but a > >> check still needs to be done. > >> > >> For example, for Kerberos PKINIT certificate which is issued to KDC we > >> don't store public certificate in LDAP either but we do two checks: > >> - a special KDC certificate profile is used to issue the cert > >> - a special hostname check is done so that only IPA masters are able to > >> request this certificate > >> > >> For the wildcard certificate I think we could have following: > >> - use a separate profile for the wildcard, associated with a sub-CA > >> - hardcode CN default in the profile to always be 'CN=*, > >> O=$SUB_CA_SUBJECT' so that > >> actual certificate ignores requested CN. > >> - a special check to be done so that only wildcard-based subject > >> alternative names can be added to a wildcard certificate request > >> - all Kerberos principal / hostname checks are skipped. > >> - actual ACL check is done by CA ACL. > >> > > Issuing wildcard certs is a deprecated practice[1]. I am not > > dismissing the needs of OpenShift (or PaaS/IaaS solutions in > > general) but I'd like to have a discussion with them about how > > they're currently dealing with certs and whether a different > > direction other than wildcard certs is feasible. Martin, who should > > I reach out to? Feel free to copy them into this discussion. > > Right now, I am talking to a Solution Architect, i.e. someone who is building > GAed solutions, not developers. This is not something we would change > short-term anyway, this is how current OpenShift v2 or v3 behaves, despite > the RFC. > > While I understand why having certificate *.lab.example.com and using it for > my > lab machines is a bad idea and increases the attack vector, I do not see it > that way for OpenShift. There, applications get URL like > ".myopenshift.test" and all is routed by one entity, the OpenShift > broker. So the key.cert is on one location, just serving different names that > are provisioned with OpenShift. > > I can understand that issuing a new certificate for every application > provisioned by OpenShift and then renewing it complicates the design > significantly. I am trying to be creative and see if current OpenShift could > leverage FreeIPA CA and issue the broker cert, with current profile > capabilities or with small change. > I believe OpenShift supports per-application certificates (i.e. when app developers/maintainers supply their own cert for a custom domain). So it might be possible in v2 or v3 to provision a cert for every app. An automated solution does not yet exist but that doesn't mean it can't be built out of what's currently GA. > > [1] https://tools.ietf.org/html/rfc6125#section-7.2 > > > > If we do go ahead with wildcard cert support in FreeIPA, some of my > > initial questions are: > > > > - For the OpenShift use case, what is the "parent" domain name and &g
Re: [Freeipa-devel] FreeIPA and wildcard certificates
On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
> On ke, 08 helmi 2017, Martin Kosek wrote:
> > Hi Fraser and the list,
> >
> > I recently was in a conversation about integrating OpenShift with FreeIPA.
> > One
> > of the gaps was around generating a wildcard certificate by FreeIPA that
> > will
> > be used in the default OpenShift router for applications that do not deploy
> > own
> > certificates [1].
> >
> > Is there any way that FreeIPA can generate it? I was thinking that uploading
> > some custom certificate profile in FreeIPA may let us get such
> > certificate...
> > Or is the the only way we can add it by adding a new RFE in FreeIPA,
> > tracked in
> > [2]?
> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
> certificates to be issued:
>
> - we ensure subject 'cn' of the certificate matches a Kerberos principal
> specified in the request
>
> - we validate that host object exists in IPA when the Kerberos
> principal is host/...
>
> We could lift off these two limitations for 'cn=*,$suffix' but there is
> still a need to apply proper ACLs when issuing the cert -- e.g. some
> object has to be used for performing access rights check. The wildcard
> certificate does not need to be stored anywhere in the tree, but a
> check still needs to be done.
>
> For example, for Kerberos PKINIT certificate which is issued to KDC we
> don't store public certificate in LDAP either but we do two checks:
> - a special KDC certificate profile is used to issue the cert
> - a special hostname check is done so that only IPA masters are able to
> request this certificate
>
> For the wildcard certificate I think we could have following:
> - use a separate profile for the wildcard, associated with a sub-CA
> - hardcode CN default in the profile to always be 'CN=*, O=$SUB_CA_SUBJECT'
> so that
> actual certificate ignores requested CN.
> - a special check to be done so that only wildcard-based subject
> alternative names can be added to a wildcard certificate request
> - all Kerberos principal / hostname checks are skipped.
> - actual ACL check is done by CA ACL.
>
Issuing wildcard certs is a deprecated practice[1]. I am not
dismissing the needs of OpenShift (or PaaS/IaaS solutions in
general) but I'd like to have a discussion with them about how
they're currently dealing with certs and whether a different
direction other than wildcard certs is feasible. Martin, who should
I reach out to? Feel free to copy them into this discussion.
[1] https://tools.ietf.org/html/rfc6125#section-7.2
If we do go ahead with wildcard cert support in FreeIPA, some of my
initial questions are:
- For the OpenShift use case, what is the "parent" domain name and
is it the same as the IPA domain name? Is it a subdomain of the
IPA domain name?
- Do we need to support issuing "*.${IPA_DOMAIN}"? i.e. wildcard
cert under entire IPA domain name.
- Do we need to support issuing "*.${IPA_HOSTNAME}"? i.e. wildcard
certs under names of IPA host principals.
Cheers,
Fraser
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag
On Wed, Feb 08, 2017 at 08:02:18AM +0100, Jan Cholasta wrote: > On 8.2.2017 07:29, Fraser Tweedale wrote: > > On Mon, Feb 06, 2017 at 10:24:31AM +0100, Jan Cholasta wrote: > > > On 17.1.2017 08:57, David Kupka wrote: > > > > On 13/01/17 08:07, Fraser Tweedale wrote: > > > > > Related to design: > > > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > > > > > > > > > Currently there are some operations that hit the CA that involve a > > > > > number of privileged operations against the CA, but for which there > > > > > is only one associated IPA permission. Deleting a CA is a good > > > > > example (but it is one specific case of a more general issue). > > > > > Summary of current ca-del behaviour: > > > > > > > > > > 1. Disable LWCA in Dogtag (uses RA Agent cert) > > > > > 2. Delete LWCA in Dogtag (uses RA Agent cert) > > > > > 3. Delete CA entry from IPA (requires "System: Delete CA" permission) > > > > > > > > > > So there are two things going on under the hood: a modify operation > > > > > (disable CA) and the delete. > > > > > > > > > > When we implement proxy authentication to Dogtag, Dogtag will > > > > > enforce the IPA permissions on its operations. Disable will map to > > > > > "System: Modify CA" and delete to "System: Delete CA". So to delete > > > > > a CA a user will need *both* permissions. Which could be > > > > > surprising. > > > > > > > > > > There are a couple of reasonable approaches to this. > > > > > > > > > > 1. Decouple the disable and delete operations. If CA is not > > > > > disabled, the user will be instructed to execute the ca-disable > > > > > command separately before they can disable the CA. This introduces > > > > > an additional manual step for operators. > > > > > > > > > > 2. Just improve the error reporting. In my WIP, for a user that has > > > > > 'System: Delete CA' permission but not 'System: Modify CA', the > > > > > reported failure is a 403 Authorization Error from Dogtag. We can > > > > > add guards to fail more gracefully. > > > > > > > > > > I lean towards #2 because I guess the common case will be that users > > > > > either get all CA admin permissions, or none, and we don't want to > > > > > make more work (in the form of more commands to run) for users in > > > > > the common case. > > > > > > > > > > I welcome alternative views and suggestions. > > > > > > > > > > Thanks, > > > > > Fraser > > > > > > > > > Hi Fraser, > > > > as a user with "System: Delete CA" permission calling "ca-del" command I > > > > would be really surprised that I don't have enough privileges to > > > > complete the action. > > > > > > > > I would expect: > > > > a) "Cannot delete active CA, disable it first" error. > > > > b) Delete will be completed successfully. All internal and to my sight > > > > hidden operations will be allowed just because I'm allowed to perform > > > > the delete operation. > > > > > > > > I think that b) might lead to strange exceptions in authorization > > > > checking and therefore to security issues. So I would prefer decoupling > > > > ca-disable and ca-del as you're describing in 1). > > > > > > IMO having to disable the CA before deletion is an implementation detail > > > and > > > should not be exposed to the user at all. Why do we have to disable the CA > > > from IPA in ca-del? I would expect Dogtag to disable it itself internally > > > when it's being deleted. > > > > > The CA requiring disablement before deletion is a property of how > > Dogtag Lightweight CAs are implement. I don't intend to change this > > (besides, it might need to be this way for Common Criteria; a > > similar restriction exists for profiles). > > OK. > > > > > We could make it so that in IPA context, delete permission implies > > disable permission. Currently (in Dogtag) permission to > > enable/disable is the 'modify' permission. So to do this without > > implying that someone with 'delete' pe
Re: [Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag
On Mon, Feb 06, 2017 at 10:24:31AM +0100, Jan Cholasta wrote: > On 17.1.2017 08:57, David Kupka wrote: > > On 13/01/17 08:07, Fraser Tweedale wrote: > > > Related to design: > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > > > > > Currently there are some operations that hit the CA that involve a > > > number of privileged operations against the CA, but for which there > > > is only one associated IPA permission. Deleting a CA is a good > > > example (but it is one specific case of a more general issue). > > > Summary of current ca-del behaviour: > > > > > > 1. Disable LWCA in Dogtag (uses RA Agent cert) > > > 2. Delete LWCA in Dogtag (uses RA Agent cert) > > > 3. Delete CA entry from IPA (requires "System: Delete CA" permission) > > > > > > So there are two things going on under the hood: a modify operation > > > (disable CA) and the delete. > > > > > > When we implement proxy authentication to Dogtag, Dogtag will > > > enforce the IPA permissions on its operations. Disable will map to > > > "System: Modify CA" and delete to "System: Delete CA". So to delete > > > a CA a user will need *both* permissions. Which could be > > > surprising. > > > > > > There are a couple of reasonable approaches to this. > > > > > > 1. Decouple the disable and delete operations. If CA is not > > > disabled, the user will be instructed to execute the ca-disable > > > command separately before they can disable the CA. This introduces > > > an additional manual step for operators. > > > > > > 2. Just improve the error reporting. In my WIP, for a user that has > > > 'System: Delete CA' permission but not 'System: Modify CA', the > > > reported failure is a 403 Authorization Error from Dogtag. We can > > > add guards to fail more gracefully. > > > > > > I lean towards #2 because I guess the common case will be that users > > > either get all CA admin permissions, or none, and we don't want to > > > make more work (in the form of more commands to run) for users in > > > the common case. > > > > > > I welcome alternative views and suggestions. > > > > > > Thanks, > > > Fraser > > > > > Hi Fraser, > > as a user with "System: Delete CA" permission calling "ca-del" command I > > would be really surprised that I don't have enough privileges to > > complete the action. > > > > I would expect: > > a) "Cannot delete active CA, disable it first" error. > > b) Delete will be completed successfully. All internal and to my sight > > hidden operations will be allowed just because I'm allowed to perform > > the delete operation. > > > > I think that b) might lead to strange exceptions in authorization > > checking and therefore to security issues. So I would prefer decoupling > > ca-disable and ca-del as you're describing in 1). > > IMO having to disable the CA before deletion is an implementation detail and > should not be exposed to the user at all. Why do we have to disable the CA > from IPA in ca-del? I would expect Dogtag to disable it itself internally > when it's being deleted. > The CA requiring disablement before deletion is a property of how Dogtag Lightweight CAs are implement. I don't intend to change this (besides, it might need to be this way for Common Criteria; a similar restriction exists for profiles). We could make it so that in IPA context, delete permission implies disable permission. Currently (in Dogtag) permission to enable/disable is the 'modify' permission. So to do this without implying that someone with 'delete' permission as 'modify' permission, I'd need to add an explicit 'enable/disable ca' permission. This is a good idea, but it is more work to add the required ACLs (which will need to be done during IPA upgrade or installation). I'll shelve https://github.com/freeipa/freeipa/pull/415 for now, but keep the patch in my working branch and code it out later, if there's time before release. Otherwise we might need to keep it until there's time for the proper fix, so that things don't break. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
On Mon, Feb 06, 2017 at 10:37:34AM +0200, Alexander Bokovoy wrote: > On ma, 06 helmi 2017, Jan Cholasta wrote: > > On 11.1.2017 02:09, Fraser Tweedale wrote: > > > On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote: > > > > Hi Fraser, > > > > > > > > I have some rather inane comments. I guess Jan cholasta will do a more > > > > thorough review of your design. See below: > > > > > > > > On 01/06/2017 09:08 AM, Fraser Tweedale wrote: > > > > > Hi comrades, > > > > > > > > > > I have written up the high-level details of the FreeIPA->Dogtag > > > > > GSS-API authentication design. The goal is improve security by > > > > > removing an egregious privilege separation violation: the RA Agent > > > > > cert. > > > > > > > > > > There is a fair bit of work still to do on the Dogtag side but > > > > > things are shaping up there and it's time to work out the IPA > > > > > aspects. The design is at: > > > > > > > > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > > > > > > > first of all, you link a internal document from publicly available > > > > design > > > > page. you should prepare a publicly visible version of the Dogtag-side > > > > design and link that. > > > > > > > Will do; thanks. > > > > > > > It would also be nice to have a high-level graphical representation of > > > > the > > > > proposed CSR processing workflow. I think you can re-use the one that > > > > is in > > > > the Dogtag part, omit the Dogtag internals and add IPA-specific parts. > > > > > > > I will definitely do this a bit later, once more details of IPA > > > design are established. > > > > > > > > > > > > > Right now, I need feedback about the Domain Level aspects: whether > > > > > it is the right approach, whether there are mechanisms to perform > > > > > update steps (specifically: LDAP updates and/or api calls) alongside > > > > > a DL bump, or if there aren't, how to deal with that (implement such > > > > > a mechanism, make admins do extra steps, ???). > > > > > > > > > > > > > Is the DL bump really necessary? Are you sure we really can not just > > > > update > > > > the profile configuration and let older Dogtag installation handle it > > > > gracefully? IIRC we have done some profile inclusion work in 4.2 > > > > development > > > > and on and never really bothered about older Dogtag understanding them. > > > > > > > The problem is that the new profiles will refer to plugins (i.e. > > > classes) that do not exist in older versions of Dogtag. Profile > > > config is replicated, so if we upgrade profile config with old > > > versions of Dogtag in the topology, it breaks them. > > > > > > I considered a mechanism where multiple versions of a profile exist > > > in LDAP (i.e. multiple attribute values), and Dogtag picks the one > > > that's "right" for it. (An example of how to do this might be > > > attribute tagging where tag indicates minimum version of Dogtag > > > containing components used in that profile version, and Dogag picks > > > the highest that it supports). The advantage of such a mechanism is > > > that we could use it for any future scenario where we introduce new > > > profile components that we want to use in IPA. The downside is that > > > it significantly complicates profile management (including for > > > administrators), and can result in the same profile having different > > > behaviour on different Dogtag instances, which could be confusing > > > and make it harder to diagnose issues. Given the tradeoffs, I think > > > a DL bump is preferable. > > > > I don't like the prospect of having to bump DL every time a new > > component is introduced. This time it might be OK, because the new DL is > > apparently required for the RA -> GSSAPI change, but IMHO in general a > > change in a certificate profile does not warrant a DL bump. > > > > I agree that maintaining multiple versions of a profile is not the way > > to go, but I think there are other options: > > > > * Change `auth.instance_id` from `raCertAuth` to a new, IPA-specific > > `ipaAuth`. Configure `aut
[Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag
Related to design: http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication Currently there are some operations that hit the CA that involve a number of privileged operations against the CA, but for which there is only one associated IPA permission. Deleting a CA is a good example (but it is one specific case of a more general issue). Summary of current ca-del behaviour: 1. Disable LWCA in Dogtag (uses RA Agent cert) 2. Delete LWCA in Dogtag (uses RA Agent cert) 3. Delete CA entry from IPA (requires "System: Delete CA" permission) So there are two things going on under the hood: a modify operation (disable CA) and the delete. When we implement proxy authentication to Dogtag, Dogtag will enforce the IPA permissions on its operations. Disable will map to "System: Modify CA" and delete to "System: Delete CA". So to delete a CA a user will need *both* permissions. Which could be surprising. There are a couple of reasonable approaches to this. 1. Decouple the disable and delete operations. If CA is not disabled, the user will be instructed to execute the ca-disable command separately before they can disable the CA. This introduces an additional manual step for operators. 2. Just improve the error reporting. In my WIP, for a user that has 'System: Delete CA' permission but not 'System: Modify CA', the reported failure is a 403 Authorization Error from Dogtag. We can add guards to fail more gracefully. I lean towards #2 because I guess the common case will be that users either get all CA admin permissions, or none, and we don't want to make more work (in the form of more commands to run) for users in the common case. I welcome alternative views and suggestions. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] GetEffectiveRights and add ACIs
In ca_add.pre_callback, we have: if not ldap.can_add(dn[1:]): raise ACIError(...) `can_add' uses the GetEffectiveRights control to see what rights the user has. When a user with the 'System: Add CA' permission attempts to add a CA, the above ACIError gets raised. This is definitely a bug. I think it is a bug in DS GetEffectiveRights code. The ACI in play is: dn: cn=cas,cn=ca,dc=ipa,dc=local aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System : Add CA";allow (add) groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn= pbac,dc=ipa,dc=local";) ... The user definitely has the right membership: dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local memberof: cn=LWCA Administration,cn=privileges,cn=pbac,dc=ipa,dc=local memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local William suggested I check whether direct vs. indirect membership made a difference. It does not. A wild guess is that the algorithm that computes whether the subject has add access under the given entry does not take the targetfilter into account. To solve, perhaps we could ignore ACI targetfilter when computing add access for GER. Alternatively, is there another way for a user to determine if they can add an entry at a particular place, without actually doing the add? Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote: > Hi Fraser, > > I have some rather inane comments. I guess Jan cholasta will do a more > thorough review of your design. See below: > > On 01/06/2017 09:08 AM, Fraser Tweedale wrote: > > Hi comrades, > > > > I have written up the high-level details of the FreeIPA->Dogtag > > GSS-API authentication design. The goal is improve security by > > removing an egregious privilege separation violation: the RA Agent > > cert. > > > > There is a fair bit of work still to do on the Dogtag side but > > things are shaping up there and it's time to work out the IPA > > aspects. The design is at: > > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > first of all, you link a internal document from publicly available design > page. you should prepare a publicly visible version of the Dogtag-side > design and link that. > Will do; thanks. > It would also be nice to have a high-level graphical representation of the > proposed CSR processing workflow. I think you can re-use the one that is in > the Dogtag part, omit the Dogtag internals and add IPA-specific parts. > I will definitely do this a bit later, once more details of IPA design are established. > > > > Right now, I need feedback about the Domain Level aspects: whether > > it is the right approach, whether there are mechanisms to perform > > update steps (specifically: LDAP updates and/or api calls) alongside > > a DL bump, or if there aren't, how to deal with that (implement such > > a mechanism, make admins do extra steps, ???). > > > > Is the DL bump really necessary? Are you sure we really can not just update > the profile configuration and let older Dogtag installation handle it > gracefully? IIRC we have done some profile inclusion work in 4.2 development > and on and never really bothered about older Dogtag understanding them. > The problem is that the new profiles will refer to plugins (i.e. classes) that do not exist in older versions of Dogtag. Profile config is replicated, so if we upgrade profile config with old versions of Dogtag in the topology, it breaks them. I considered a mechanism where multiple versions of a profile exist in LDAP (i.e. multiple attribute values), and Dogtag picks the one that's "right" for it. (An example of how to do this might be attribute tagging where tag indicates minimum version of Dogtag containing components used in that profile version, and Dogag picks the highest that it supports). The advantage of such a mechanism is that we could use it for any future scenario where we introduce new profile components that we want to use in IPA. The downside is that it significantly complicates profile management (including for administrators), and can result in the same profile having different behaviour on different Dogtag instances, which could be confusing and make it harder to diagnose issues. Given the tradeoffs, I think a DL bump is preferable. > Anyway I guess we can call `certprofile-import' to load > ExternalProcessConstraint-enabled profile upon setting domain level to 2, we > just have to know where on the FS it is located. > > > Of course, any other general or specific feedback is welcome. > > > > Thanks, > > Fraser > > > > So if I understand correctly there will be no change in CA ACL management > interface and only the code which evaluates them will be factored out into > 'ipa-pki-validate-cert-request' command? Also, wouldn't it simpler if the CA > ACL evaluation was delegated to a separate API command instead? > ExternalProcessConstraint would then only ask IPA JSON api and process the > response. > There are no changes to CA ACL management interface as part of this design, but there are proposals to extend/rework it in future, e.g. #6424, #6425, #6426. Having a separate command for CA ACL evaluation is a good idea, and a clean refactoring target. ExternalProcessConstraint is generic with no knowledge of IPA API, but 'pki-pki-validate-cert-request' can invoke the new API command. Thanks for your feedback, Martin! Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication
Hi comrades, I have written up the high-level details of the FreeIPA->Dogtag GSS-API authentication design. The goal is improve security by removing an egregious privilege separation violation: the RA Agent cert. There is a fair bit of work still to do on the Dogtag side but things are shaping up there and it's time to work out the IPA aspects. The design is at: http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication Right now, I need feedback about the Domain Level aspects: whether it is the right approach, whether there are mechanisms to perform update steps (specifically: LDAP updates and/or api calls) alongside a DL bump, or if there aren't, how to deal with that (implement such a mechanism, make admins do extra steps, ???). Of course, any other general or specific feedback is welcome. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] CI: exporting test runner output
On Thu, Jan 05, 2017 at 09:38:03AM +0100, Tomas Krizek wrote: > On 01/05/2017 09:25 AM, Fraser Tweedale wrote: > > On Thu, Jan 05, 2017 at 08:53:14AM +0100, Martin Babinsky wrote: > >> On 01/05/2017 08:06 AM, Fraser Tweedale wrote: > >>> Hi all, > >>> > >>> Although it has been discussed before and met with some skepticism, > >>> here is a POC that exporting test runner output to, e.g. a pastebin, > >>> does work: > >>> > >>> - experimental commit: https://github.com/freeipa/freeipa/pull/370 > >>> - example paste: https://paste.fedoraproject.org/520085/ > >>> (it is gzipped for reasons discussed in the PR) > >>> > >>> I think we should proceed with getting these artifacts out of Travis > >>> and stored somewhere (it doesn't have to be > >>> paste.fedoraproject.org). ``tail -n 5000`` of the log file has > >>> proven to be not enough to diagnose all failures. > >>> > >> Wow this is great, why have I not thought about it beforehand? > Seems like a great feature. Thanks, Fraser! > >> We can reduce the log size if we truncate everything before ERRORS/FAILURES > >> output of pytest run (we leave the log as it is if the fail occurs before > >> this stage), that should shave off considerable amount of cruft from the > >> paste unless somebody sends a PR that breaks all out tests :D. > >> > >>> If we stick with paste.fedoraproject.org, we can send to a > >>> "project-specific" namespace e.g. > >>> https://paste.fedoraproject.org/~freeipa, so that we do not clutter > >>> up the main archive (I think). > >>> I was wrong. All "project" pastes appear in main namespace as well as project namespace. Not sure if by design or not. > >>> A few questions for discussion: > >>> > >>> 1. Stick with fpaste or not? If so, use "~freeipa" namespace? > >>>(Keep in mind that the size limitation that exists for fpaste, > >>>which requires compressing the artifact, may not be a problem > >>>elsewhere). > >>> > >>> 2. Export log always, or only if the build job failed? > >>> > >> I would also paste the output to "freeipa" or even better "freeipa-travis" > >> namespace and only send it if the job fails. > >> > > I might go with "freeipa-ci". > +1 > Unfortunately fpaste can't handle this. Has to be all-alpha. So we can use "freeipaci" but given the constraint I would rather just use "freeipa". I shall file a fedora-infra ticket to see if this can be addressed. > >>> 3. Should pasted logs expire? If so, what should TTL be? > >>> > >> IMHO yes, but TTL is hard to determine, since the author of the PR may not > >> be present to review the results immediately (because he is on PTO etc.). I > >> think we should set TTL to something like 1 week and as a fallback keep > >> tailing the CI results log. > >> > > 1 week sounds reasonable. We can change it later if we need to. > I actually wouldn't mind extending this to something like 2-4 weeks. In > some cases it might be useful to have access to older logs (PTOs, or > simply to just view the history for some reason). Is there any downside > to keeping the logs for a bit longer? > Not really. I was thinking server diskspace is logs were very big but now that we're compressing I don't think it matters. 4 weeks, sure why not :) > >>> 4. Should we continue to `tail -n 5000` the log as we currently do, > >>>or just rely on exported log? > If you're talking about the log in the travis web interface, I would > keep it. It's easily accessible from the browser. > >>> Thanks, > >>> Fraser > >> Fraser, are you OK with waiting with this effort until we push > >> https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more > >> adjustments there (like result log trimming) and it should be pushed ASAP. > >> > > Yes, I was aware that there would be conflicts with this PR. I > > don't mind waiting. Thanks for your input. > > > > Cheers, > > Fraser > > > -- > Tomas Krizek > > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] CI: exporting test runner output
On Thu, Jan 05, 2017 at 08:53:14AM +0100, Martin Babinsky wrote: > On 01/05/2017 08:06 AM, Fraser Tweedale wrote: > > Hi all, > > > > Although it has been discussed before and met with some skepticism, > > here is a POC that exporting test runner output to, e.g. a pastebin, > > does work: > > > > - experimental commit: https://github.com/freeipa/freeipa/pull/370 > > - example paste: https://paste.fedoraproject.org/520085/ > > (it is gzipped for reasons discussed in the PR) > > > > I think we should proceed with getting these artifacts out of Travis > > and stored somewhere (it doesn't have to be > > paste.fedoraproject.org). ``tail -n 5000`` of the log file has > > proven to be not enough to diagnose all failures. > > > Wow this is great, why have I not thought about it beforehand? > > We can reduce the log size if we truncate everything before ERRORS/FAILURES > output of pytest run (we leave the log as it is if the fail occurs before > this stage), that should shave off considerable amount of cruft from the > paste unless somebody sends a PR that breaks all out tests :D. > > > If we stick with paste.fedoraproject.org, we can send to a > > "project-specific" namespace e.g. > > https://paste.fedoraproject.org/~freeipa, so that we do not clutter > > up the main archive (I think). > > > > A few questions for discussion: > > > > 1. Stick with fpaste or not? If so, use "~freeipa" namespace? > >(Keep in mind that the size limitation that exists for fpaste, > >which requires compressing the artifact, may not be a problem > >elsewhere). > > > > 2. Export log always, or only if the build job failed? > > > I would also paste the output to "freeipa" or even better "freeipa-travis" > namespace and only send it if the job fails. > I might go with "freeipa-ci". > > 3. Should pasted logs expire? If so, what should TTL be? > > > IMHO yes, but TTL is hard to determine, since the author of the PR may not > be present to review the results immediately (because he is on PTO etc.). I > think we should set TTL to something like 1 week and as a fallback keep > tailing the CI results log. > 1 week sounds reasonable. We can change it later if we need to. > > 4. Should we continue to `tail -n 5000` the log as we currently do, > >or just rely on exported log? > > > > Thanks, > > Fraser > > > > Fraser, are you OK with waiting with this effort until we push > https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more > adjustments there (like result log trimming) and it should be pushed ASAP. > Yes, I was aware that there would be conflicts with this PR. I don't mind waiting. Thanks for your input. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] CI: exporting test runner output
Hi all, Although it has been discussed before and met with some skepticism, here is a POC that exporting test runner output to, e.g. a pastebin, does work: - experimental commit: https://github.com/freeipa/freeipa/pull/370 - example paste: https://paste.fedoraproject.org/520085/ (it is gzipped for reasons discussed in the PR) I think we should proceed with getting these artifacts out of Travis and stored somewhere (it doesn't have to be paste.fedoraproject.org). ``tail -n 5000`` of the log file has proven to be not enough to diagnose all failures. If we stick with paste.fedoraproject.org, we can send to a "project-specific" namespace e.g. https://paste.fedoraproject.org/~freeipa, so that we do not clutter up the main archive (I think). A few questions for discussion: 1. Stick with fpaste or not? If so, use "~freeipa" namespace? (Keep in mind that the size limitation that exists for fpaste, which requires compressing the artifact, may not be a problem elsewhere). 2. Export log always, or only if the build job failed? 3. Should pasted logs expire? If so, what should TTL be? 4. Should we continue to `tail -n 5000` the log as we currently do, or just rely on exported log? Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Travis CI broke after merging PR 177
On Tue, Dec 13, 2016 at 01:11:37PM +0100, Martin Babinsky wrote: > On 12/13/2016 01:07 PM, Fraser Tweedale wrote: > > On Tue, Dec 13, 2016 at 09:41:40AM +0100, Martin Babinsky wrote: > > > Hi list, > > > > > > https://github.com/freeipa/freeipa/pull/177 was recently merged despite > > > causing nearly half of the tests in our Travis CI gating to fail. This > > > broke > > > Travis CI for all other PR that were rebased after this merge, causing > > > false > > > negative errors everywhere. > > > > > > Fraser reverted the offending commits in > > > https://github.com/freeipa/freeipa/pull/329 which restored Travis to > > > original state (never mind PEP8 errors they were in the original code > > > already). > > > > > > Regarding this issues I have two questions: > > > > > > a) > > > > > > should I merge https://github.com/freeipa/freeipa/pull/329 and thus revert > > > the breakage in order to unblock other contributors? Given the current > > > traffic I think it is sufficient to wait for us to investigate and > > > produce a > > > fix. If not, please scream loudly. > > > > > Definitely not, I am using this PR as a playground to poke the CI in > > various ways. Also, proper fix would be best :) See also my other > > mail (I would have replied here but fetchmail was not fetching mail > > and I missed it until just now >_<). > > > > > b) > > > > > > what can we improve to make the results of CI more visible to > > > contributors? > > > I think that I should sit down with Martin 2 and investigate the > > > possibility > > > to send notifications about negative CI results (sufficient IMO) to the > > > mailing list. > > > > > Or the commit author. > > > > It would be *great* if the test job, in event of failure, would > > collect all the obvious logs and dump them somewhere as artifacts. > > > > That would be great but AFAIK Travis CI does support only archiving > artifacts into a running AWS instance[1] which we do not have and would have > to buy, run and maintain ourselves. For now we have to inspect the log dumps > generated in the job output. > Do the containers not have internet access? That is all you really need, surely. The log dumps are not enough... `tail -n 5000' is not enough :) Even if there is no other way besides S3, it might still be worth it. > > > In the meanwhile I would like to ask all reviewers to carefully check the > > > output of failed Travis CI runs. If the job fails, you will see the > > > results > > > at the very end of the log. There are two sections: PEP8 errors and test > > > output. You can expand both of them to see what went wrong and report it > > > to > > > the PR author if necessary. > > > > > > The reviewer and author can then use the very same tool used in CI [1] to > > > reproduce the failures locally. Using '--no-cleanup' option during the > > > run > > > [2] leaves behind a running container which you can attach to and > > > investigate further. > > > > > > [1] https://github.com/freeipa/ipa-docker-test-runner > > > [2] > > > https://github.com/freeipa/ipa-docker-test-runner/blob/master/README.md > > > > > > If you have any additional questions/suggestions about Travis feel free to > > > contact me. > > > > > > -- > > > Martin^3 Babinsky > > > > > > -- > > > Manage your subscription for the Freeipa-devel mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > [1] https://docs.travis-ci.com/user/uploading-artifacts/ > > -- > Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Travis CI broke after merging PR 177
On Tue, Dec 13, 2016 at 09:41:40AM +0100, Martin Babinsky wrote: > Hi list, > > https://github.com/freeipa/freeipa/pull/177 was recently merged despite > causing nearly half of the tests in our Travis CI gating to fail. This broke > Travis CI for all other PR that were rebased after this merge, causing false > negative errors everywhere. > > Fraser reverted the offending commits in > https://github.com/freeipa/freeipa/pull/329 which restored Travis to > original state (never mind PEP8 errors they were in the original code > already). > > Regarding this issues I have two questions: > > a) > > should I merge https://github.com/freeipa/freeipa/pull/329 and thus revert > the breakage in order to unblock other contributors? Given the current > traffic I think it is sufficient to wait for us to investigate and produce a > fix. If not, please scream loudly. > Definitely not, I am using this PR as a playground to poke the CI in various ways. Also, proper fix would be best :) See also my other mail (I would have replied here but fetchmail was not fetching mail and I missed it until just now >_<). > b) > > what can we improve to make the results of CI more visible to contributors? > I think that I should sit down with Martin 2 and investigate the possibility > to send notifications about negative CI results (sufficient IMO) to the > mailing list. > Or the commit author. It would be *great* if the test job, in event of failure, would collect all the obvious logs and dump them somewhere as artifacts. > In the meanwhile I would like to ask all reviewers to carefully check the > output of failed Travis CI runs. If the job fails, you will see the results > at the very end of the log. There are two sections: PEP8 errors and test > output. You can expand both of them to see what went wrong and report it to > the PR author if necessary. > > The reviewer and author can then use the very same tool used in CI [1] to > reproduce the failures locally. Using '--no-cleanup' option during the run > [2] leaves behind a running container which you can attach to and > investigate further. > > [1] https://github.com/freeipa/ipa-docker-test-runner > [2] https://github.com/freeipa/ipa-docker-test-runner/blob/master/README.md > > If you have any additional questions/suggestions about Travis feel free to > contact me. > > -- > Martin^3 Babinsky > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] CI failures - I need your help
Hi all, The CI failures caused by one of my recent commits have me baffled. It is exactly this commit[1] at which the problems begin. I cannot see anything in the commit to point a finger at. In-tree tests run fine. [1] https://github.com/freeipa/freeipa/commit/32b1743e5fb318b226a602ec8d9a4b6ef2a25c9d In terms of symptoms: a Travis run has two jobs, one dealing with `test_xmlrpc/test_[a-k]*.py' and the other dealing with `test_xmlrpc/test_[l-z]*.py' as well as `test_install/', `test_ipalib/', `test_ipapython/', `test_ipaserver/' and `test_pkcs10'. See [2] for an example of a failing build: the first job (which includes tests for the ca plugin, which is what the patch relates to) does succeed, but the second fails catastrophically with myriad occurences of: E NetworkError: cannot connect to 'https://master1.ipa.test/ipa/session/json': (SSL_ERROR_NO_CIPHERS_SUPPORTED) No cipher suites are present and enabled in this program. Leading to the unfortunate outcome: === 254 failed, 576 passed, 98 skipped, 1756 error in 254.59 seconds === [2] https://travis-ci.org/freeipa/freeipa/builds/183544973 I have been unsuccessful in running `ipa-docker-test-runner' on my own machine due to Java thread creation problems, so I need the help of others to analyse and fix this issue. If someone was able to analyse a running container that had the test failures, send logs, or even make an image of the container and upload it somewhere for me, it might lead to some answers. Thanks for your help. Fraser (P.S. I hope it is not a trivial thing I have overlook ^_^) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] CSR autogeneration next steps
On Mon, Dec 12, 2016 at 02:04:37PM +0100, Jan Cholasta wrote: > On 12.12.2016 13:49, Fraser Tweedale wrote: > > (This is a tangential discussion, but...) > > > > On Mon, Dec 12, 2016 at 09:52:02AM +0100, Jan Cholasta wrote: > > > IMO profile ID should default to caIPAserviceCert on the client as well. > > > > > NACK. Default profile (although fixed at the present time) should > > be considered server-side policy. If we eventually make it > > configurable, we don't want older clients overriding it. > > I didn't mean the default value should be overriden on the clients, just > that profile ID should stay optional on the client and use the default > profile ID when unspecified. > OK, thanks for clarifying. > > > > Thanks, > > Fraser > > > > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] cannot edit freeipa.org wiki
Hi, I can no longer create or edit pages on the FreeIPA wiki. Could someone who administers the wiki help out? (Please follow up off-list.) Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Configuring ipa-otpd error when selinux is enable
On Tue, Nov 08, 2016 at 10:29:29AM +0800, 郑磊 wrote: > Hello everyone, > > I have successfully set up the FreeIPA environment on Ubuntu when selinux is > disable. But when selinux is enable, there is a configuring ipa-otpd error > occurred. > > The ipaserver-install.log shows following informations: > 2016-11-08T01:55:18Z DEBUG [1/2]: starting ipa-otpd > 2016-11-08T01:55:18Z DEBUG Starting external process > 2016-11-08T01:55:18Z DEBUG args=/bin/systemctl is-active ipa-otpd.socket > 2016-11-08T01:55:18Z DEBUG Process finished, return code=3 > 2016-11-08T01:55:18Z DEBUG stdout=inactive > > 2016-11-08T01:55:18Z DEBUG stderr= > 2016-11-08T01:55:18Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-11-08T01:55:18Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-11-08T01:55:18Z DEBUG Starting external process > 2016-11-08T01:55:18Z DEBUG args=/bin/systemctl restart ipa-otpd.socket > 2016-11-08T01:55:18Z DEBUG Process finished, return code=1 > 2016-11-08T01:55:18Z DEBUG stdout= > 2016-11-08T01:55:18Z DEBUG stderr=Job for ipa-otpd.socket failed. See > "systemctl status ipa-otpd.socket" and "journalctl -xe" for details. > > 2016-11-08T01:55:18Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line > 447, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line > 437, in run_step > method() > File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line > 585, in __start > self.restart() > File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line > 347, in restart > self.service.restart(instance_name, capture_output=capture_output, > wait=wait) > File "/usr/lib/python2.7/dist-packages/ipaplatform/base/services.py", line > 301, in restart > skip_output=not capture_output) > File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 479, in > run > raise CalledProcessError(p.returncode, arg_string, str(output)) > CalledProcessError: Command '/bin/systemctl restart ipa-otpd.socket' returned > non-zero exit status 1 > > 2016-11-08T01:55:18Z DEBUG [error] CalledProcessError: Command > '/bin/systemctl restart ipa-otpd.socket' returned non-zero exit status 1 > 2016-11-08T01:55:18Z DEBUG File > "/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", line 318, > in run > cfgr.run() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 310, in run > self.execute() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 332, in execute > for nothing in self._executor(): > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 362, in __runner > step() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 81, > in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 59, > in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 586, in _configure > next(executor) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 362, in __runner > step() > File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", line > 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 81, > in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", line 59, > in
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
Patches have been reborn as https://github.com/freeipa/freeipa/pull/177. Brief commentary inline. If any further issues, let us continue discussion at GitHub. Thanks, Fraser On Thu, Oct 06, 2016 at 10:02:55AM +0200, Jan Cholasta wrote: > On 23.9.2016 05:29, Fraser Tweedale wrote: > > Bump for review. > > > > Rebased patches attached (there was a trivial conflict in imports). > > > > Thanks, > > Fraser > > > > On Tue, Sep 06, 2016 at 02:05:06AM +1000, Fraser Tweedale wrote: > > > On Fri, Aug 26, 2016 at 10:28:58AM +0200, Jan Cholasta wrote: > > > > On 19.8.2016 13:11, Fraser Tweedale wrote: > > > > > Bump for review. > > > > > > > > > > On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > > > > > > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > > > > > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > > > > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > > > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta > > > > > > > > > > wrote: > > > > > > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > > > > > > Please review the attached patch with adds > > > > > > > > > > > > > > --certificate-out and > > > > > > > > > > > > > > --certificate-chain-out options to `ca-show' > > > > > > > > > > > > > > command. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes > > > > > > > > > > > > > > a bogus file due > > > > > > > > > > > > > > to a bug in Dogtag that will be fixed in this > > > > > > > > > > > > > > week's build. > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on > > > > > > > > > > > > > the client side, not > > > > > > > > > > > > > on the server side. > > > > > > > > > > > > > > > > > > > > > > > > > Will option defined on client side be propagated to, > > > > > > > > > > > > and observable > > > > > > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to > > > > > > > > > > > > observe that > > > > > > > > > > > > *-out has been requested and executes additional > > > > > > > > > > > > command(s) on that > > > > > > > > > > > > basis. > > > > > > > > > > > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > > > > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > > > > > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > > > > > > cert_request, cert_status, ca_del) but these all hit Dogtag > > > > > > > > anyway > > > > > > > > so I suppose that's fine. I'll return the cert *and* the chain > > > > > > > > in > > > > > > > > separate attributes, unconditionally. > > > > > >
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Fri, Oct 07, 2016 at 09:35:00AM +0300, Alexander Bokovoy wrote: > On pe, 07 loka 2016, Fraser Tweedale wrote: > > On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > > > > > Question, do we need search-and-replace at all (or at this > > > stage)? Most of the interesting values from the SAN should be > > > directly map-able to LDAP attributes. And processing the string > > > representation of might be tricky as discussed below. > > > Nevertheless the following might be possible: > > > > > > * /regexp/replacement/ > > > * /regexp/replacement/ > > > > > > where "/regexp/replacement/" stands for optional sed-like > > > substitution rules. E.g. a rule like > > > > > >/^CN=\([^,]*\).*$/\1/ > > > > > > would take the subject string > > > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > > > generate a LDAP search filter component > > > '(samAccountName=Certuser)' which can be included in a LDAP search > > > filter which includes additional components like e.g. an > > > objectClass. > > > > > A counter-proposal w.r.t. DN mapping: > > > > > > > > Where OID is either an actual OID or the corresponding string i.e. > > "CN", "O", etc. This would extract the "most specific" (leftmost in > > the LDAP sense, rightmost in the X.500 sense) attribute value of the > > specified type from the Subject DN. > > > > IMO this would cover most DN mapping use cases whilst avoiding regex > > or confusion about RDN order. Therefore your original example of: > > > >/^CN=\([^,]*\).*$/\1/ > > > > can be accomplished with: > > > > > > > > In the spirit of "make the simple things simple, and the hard things > > possible" it is probably necessary to retain the regex variant to > > handle more complex DN mapping use cases, e.g. where there are > > multiple occurrences of a single attribute type, a particular fixed > > RDN must be matched, etc. > > > > w.r.t. SAN mapping, I concur that search/replace is probably not > > needed. > How all these syntax extensions are going to handle multi-valued RDN? > In the variant I proposed, it is handled fine because it selects the "most specific" occurrence of that attribute type. An attribute type cannot appear twice in the same RDN so this is unambiguous. For the regex variant, because `RDN ::= SET OF AVA' we would have to ensure that the stringified DN uses a deterministic order for attribute types (probably lexicographic order on corresponding LDAP attribute name) within a multi-valued RDN and clearly document this. It will be up to admins to define the correct regex based on naming of the certificates they use. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > Question, do we need search-and-replace at all (or at this > stage)? Most of the interesting values from the SAN should be > directly map-able to LDAP attributes. And processing the string > representation of might be tricky as discussed below. > Nevertheless the following might be possible: > > * /regexp/replacement/ > * /regexp/replacement/ > > where "/regexp/replacement/" stands for optional sed-like > substitution rules. E.g. a rule like > >/^CN=\([^,]*\).*$/\1/ > > would take the subject string > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > generate a LDAP search filter component > '(samAccountName=Certuser)' which can be included in a LDAP search > filter which includes additional components like e.g. an > objectClass. > A counter-proposal w.r.t. DN mapping: Where OID is either an actual OID or the corresponding string i.e. "CN", "O", etc. This would extract the "most specific" (leftmost in the LDAP sense, rightmost in the X.500 sense) attribute value of the specified type from the Subject DN. IMO this would cover most DN mapping use cases whilst avoiding regex or confusion about RDN order. Therefore your original example of: /^CN=\([^,]*\).*$/\1/ can be accomplished with: In the spirit of "make the simple things simple, and the hard things possible" it is probably necessary to retain the regex variant to handle more complex DN mapping use cases, e.g. where there are multiple occurrences of a single attribute type, a particular fixed RDN must be matched, etc. w.r.t. SAN mapping, I concur that search/replace is probably not needed. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0107 Fix cert revocation when removing all certs via host/service-mod
Bump for review.
On Wed, Sep 07, 2016 at 04:06:25PM +0700, Fraser Tweedale wrote:
> Attached patch fixes https://fedorahosted.org/freeipa/ticket/6305
>
> Thanks,
> Fraser
> From d4d7e77795f96a4970058e61d99c70522689b22d Mon Sep 17 00:00:00 2001
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: Wed, 7 Sep 2016 19:00:18 +1000
> Subject: [PATCH] Fix cert revocation when removing all certs via
> host/service-mod
>
> When removing all host/service certificates via host/service-mod
> --certificate=, the removed certificates should be revoked, but they
> are not. Examine whether the --certificate option was provided to
> determine whether certs should be revoked, instead of looking for a
> cert list in the options (which in this case is empty).
>
> Fixes: https://fedorahosted.org/freeipa/ticket/6305
> ---
> ipaserver/plugins/host.py| 3 ++-
> ipaserver/plugins/service.py | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
> index
> 2362b6247af87b4ce63c21083e6bc8ac39db0804..7f63e94849b4a6f2ce871ec77b188c54d640ba94
> 100644
> --- a/ipaserver/plugins/host.py
> +++ b/ipaserver/plugins/host.py
> @@ -898,7 +898,8 @@ class host_mod(LDAPUpdate):
> certs_der = [x509.normalize_certificate(c) for c in certs]
>
> # revoke removed certificates
> -if certs and self.api.Command.ca_is_enabled()['result']:
> +ca_is_enabled = self.api.Command.ca_is_enabled()['result']
> +if 'usercertificate' in options and ca_is_enabled:
> try:
> entry_attrs_old = ldap.get_entry(dn, ['usercertificate'])
> except errors.NotFound:
> diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py
> index
> 093525f2e7cb84b18f0658dcb5d7c786e45c6ab6..c0590732470ac1200d4dd4ea1f089e4384a509b3
> 100644
> --- a/ipaserver/plugins/service.py
> +++ b/ipaserver/plugins/service.py
> @@ -701,7 +701,8 @@ class service_mod(LDAPUpdate):
> certs = entry_attrs.get('usercertificate') or []
> certs_der = [x509.normalize_certificate(c) for c in certs]
> # revoke removed certificates
> -if certs and self.api.Command.ca_is_enabled()['result']:
> +ca_is_enabled = self.api.Command.ca_is_enabled()['result']
> +if 'usercertificate' in options and ca_is_enabled:
> try:
> entry_attrs_old = ldap.get_entry(dn, ['usercertificate'])
> except errors.NotFound:
> --
> 2.5.5
>
> --
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
Bump for review. Rebased patches attached (there was a trivial conflict in imports). Thanks, Fraser On Tue, Sep 06, 2016 at 02:05:06AM +1000, Fraser Tweedale wrote: > On Fri, Aug 26, 2016 at 10:28:58AM +0200, Jan Cholasta wrote: > > On 19.8.2016 13:11, Fraser Tweedale wrote: > > > Bump for review. > > > > > > On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > > > > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > > > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta > > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > > > > Please review the attached patch with adds > > > > > > > > > > > > --certificate-out and > > > > > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a > > > > > > > > > > > > bogus file due > > > > > > > > > > > > to a bug in Dogtag that will be fixed in this week's > > > > > > > > > > > > build. > > > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the > > > > > > > > > > > client side, not > > > > > > > > > > > on the server side. > > > > > > > > > > > > > > > > > > > > > Will option defined on client side be propagated to, and > > > > > > > > > > observable > > > > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to > > > > > > > > > > observe that > > > > > > > > > > *-out has been requested and executes additional command(s) > > > > > > > > > > on that > > > > > > > > > > basis. > > > > > > > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > > > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > > > > > so I suppose that's fine. I'll return the cert *and* the chain in > > > > > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information > > > > > > > > > > > included in summary > > > > > > > > > > > (and it definitely should not be multi-line). I would > > > > > > > > > > > rather inform the user > > > > > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > > > > > > > > > I was just following the pattern of other commands that > > > > > > > > > > write certs, > > > > > > > > > > profile config, etc. Apart from consistency with other > > > > > > > > > > commands I > > >
Re: [Freeipa-devel] [PATCH] 0108 cert-request: raise error when request fails
On Thu, Sep 08, 2016 at 01:15:03PM +0200, Martin Babinsky wrote: > On 09/08/2016 04:00 AM, Fraser Tweedale wrote: > > The attached patch fixes regression in cert-request: > > https://fedorahosted.org/freeipa/ticket/6309 > > > > Thanks, > > Fraser > > > > ACK. Does this patch also fix the (reopened) > https://fedorahosted.org/freeipa/ticket/3473 ? > It does not. There's much more work to do on #3473. It has only been a little bit done because I needed to switch ra.request_certificate to REST API so we can properly detect failure due to CA-disabled condition. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0108 cert-request: raise error when request fails
The attached patch fixes regression in cert-request:
https://fedorahosted.org/freeipa/ticket/6309
Thanks,
Fraser
From b27eef53ee36b7cae70206c37dea6aaa3bcfc940 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 8 Sep 2016 11:56:16 +1000
Subject: [PATCH] cert-request: raise error when request fails
Fix a regression in recent change to request cert via Dogtag REST
API. 'ra.request_certificate' was no longer raising
CertificateOperationError when the cert request failed. Inspect the
request result to determine if the request completed, and raise if
it did not.
Fixes: https://fedorahosted.org/freeipa/ticket/6309
---
ipaserver/plugins/dogtag.py | 4
1 file changed, 4 insertions(+)
diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index
77d24731bbc102ace3123a6fe41a631ea7c24f3b..644b41e90f2d377ae9b70cf4719ab8789fdfc649
100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -1678,6 +1678,10 @@ class ra(rabase.rabase, RestClient):
return cmd_result
certinfo = entries[0]
+if certinfo['requestStatus'] != 'complete':
+raise errors.CertificateOperationError(
+error=certinfo.get('errorMessage'))
+
if 'certId' in certinfo:
cmd_result = self.get_certificate(certinfo['certId'])
cert = ''.join(cmd_result['certificate'].splitlines())
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0107 Fix cert revocation when removing all certs via host/service-mod
Attached patch fixes https://fedorahosted.org/freeipa/ticket/6305
Thanks,
Fraser
From d4d7e77795f96a4970058e61d99c70522689b22d Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 7 Sep 2016 19:00:18 +1000
Subject: [PATCH] Fix cert revocation when removing all certs via
host/service-mod
When removing all host/service certificates via host/service-mod
--certificate=, the removed certificates should be revoked, but they
are not. Examine whether the --certificate option was provided to
determine whether certs should be revoked, instead of looking for a
cert list in the options (which in this case is empty).
Fixes: https://fedorahosted.org/freeipa/ticket/6305
---
ipaserver/plugins/host.py| 3 ++-
ipaserver/plugins/service.py | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
index
2362b6247af87b4ce63c21083e6bc8ac39db0804..7f63e94849b4a6f2ce871ec77b188c54d640ba94
100644
--- a/ipaserver/plugins/host.py
+++ b/ipaserver/plugins/host.py
@@ -898,7 +898,8 @@ class host_mod(LDAPUpdate):
certs_der = [x509.normalize_certificate(c) for c in certs]
# revoke removed certificates
-if certs and self.api.Command.ca_is_enabled()['result']:
+ca_is_enabled = self.api.Command.ca_is_enabled()['result']
+if 'usercertificate' in options and ca_is_enabled:
try:
entry_attrs_old = ldap.get_entry(dn, ['usercertificate'])
except errors.NotFound:
diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py
index
093525f2e7cb84b18f0658dcb5d7c786e45c6ab6..c0590732470ac1200d4dd4ea1f089e4384a509b3
100644
--- a/ipaserver/plugins/service.py
+++ b/ipaserver/plugins/service.py
@@ -701,7 +701,8 @@ class service_mod(LDAPUpdate):
certs = entry_attrs.get('usercertificate') or []
certs_der = [x509.normalize_certificate(c) for c in certs]
# revoke removed certificates
-if certs and self.api.Command.ca_is_enabled()['result']:
+ca_is_enabled = self.api.Command.ca_is_enabled()['result']
+if 'usercertificate' in options and ca_is_enabled:
try:
entry_attrs_old = ldap.get_entry(dn, ['usercertificate'])
except errors.NotFound:
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Wed, Sep 07, 2016 at 10:39:59AM +0200, Jan Cholasta wrote:
> On 7.9.2016 10:28, Fraser Tweedale wrote:
> > On Wed, Sep 07, 2016 at 08:32:42AM +0200, Jan Cholasta wrote:
> > > On 6.9.2016 19:36, Fraser Tweedale wrote:
> > > > On Tue, Sep 06, 2016 at 10:19:14AM +0200, Jan Cholasta wrote:
> > > > > On 5.9.2016 17:30, Fraser Tweedale wrote:
> > > > > > On Mon, Sep 05, 2016 at 11:59:11PM +1000, Fraser Tweedale wrote:
> > > > > > > On Tue, Aug 30, 2016 at 10:39:16AM +0200, Jan Cholasta wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On 26.8.2016 07:42, Fraser Tweedale wrote:
> > > > > > > > > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale
> > > > > > > > > wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > Attached patch fixes
> > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6221.
> > > > > > > > > > It depends on Honza's PR #20
> > > > > > > > > > https://github.com/freeipa/freeipa/pull/20.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Fraser
> > > > > > > > > >
> > > > > > > > > It does help to attach the patch :)
> > > > > > > >
> > > > > > > > I think it would be better to call cert-find once per
> > > > > > > > host-del/service-del
> > > > > > > > with the --host/--service option specified. That way you'll get
> > > > > > > > all
> > > > > > > > certificates for the given host/service at once.
> > > > > > > >
> > > > > > > > Honza
> > > > > > > >
> > > > > > > I agree that is a nicer approach.
> > > > > > >
> > > > > > > 'revoke_certs' is called from several other places besides just
> > > > > > > host/service_del. If we want to land this fix Real Soon I'd
> > > > > > > suggest
> > > > > > > we either:
> > > > > > >
> > > > > > > A) Define function 'revoke_certs_from_cert_find', call it from
> > > > > > > host/service_del, and leave 'revoke_certs' alone; or
> > > > > > >
> > > > > > > B) Land the patch as-is and do a bigger refactor at a later time.
> > > > > > >
> > > > > > > What do you think?
> > > > >
> > > > Updated patch attached; comments inline.
> > > >
> > > > > C) Use cert-find-based revoke_certs() everywhere; use the
> > > > > --certificate
> > > > > option of cert-find in the other places to get information about
> > > > > specific
> > > > > certificates.
> > > > >
> > > > As discussed on IRC, I have implemented this option. The caveat is
> > > > that for host/service-mod, we incur call to cert_find for each
> > > > removed certificate.
> > >
> > > It's worth noting that A) and B) suffer from the same caveat.
> > >
> > > >
> > > > > > >
> > > > > > Updated patch for option (A) is attached.
> > > > >
> > > > > 1) Instead of
> > > > >
> > > > > if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}:
> > > > >
> > > > > use:
> > > > >
> > > > > if result['revoked']:
> > > > >
> > > > Done.
> > > >
> > > > >
> > > > > 2)
> > > > >
> > > > > +if 'cacn' not in cert:
> > > > > +# cert is known to Dogtag, but CA appears to have been
> > > > > +# deleted. We cannot revoke this cert via IPA anymore.
> > > > > +# We could go directly to Dogtag to revoke it, but the
> > > > > +# issuer's cert should have been revoked so never mind.
> > > > > +continue
> > > > >
> > > > > Or, it could be a cert issued by a 3rd party CA.
> > > > >
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Wed, Sep 07, 2016 at 08:32:42AM +0200, Jan Cholasta wrote:
> On 6.9.2016 19:36, Fraser Tweedale wrote:
> > On Tue, Sep 06, 2016 at 10:19:14AM +0200, Jan Cholasta wrote:
> > > On 5.9.2016 17:30, Fraser Tweedale wrote:
> > > > On Mon, Sep 05, 2016 at 11:59:11PM +1000, Fraser Tweedale wrote:
> > > > > On Tue, Aug 30, 2016 at 10:39:16AM +0200, Jan Cholasta wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 26.8.2016 07:42, Fraser Tweedale wrote:
> > > > > > > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Attached patch fixes
> > > > > > > > https://fedorahosted.org/freeipa/ticket/6221.
> > > > > > > > It depends on Honza's PR #20
> > > > > > > > https://github.com/freeipa/freeipa/pull/20.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Fraser
> > > > > > > >
> > > > > > > It does help to attach the patch :)
> > > > > >
> > > > > > I think it would be better to call cert-find once per
> > > > > > host-del/service-del
> > > > > > with the --host/--service option specified. That way you'll get all
> > > > > > certificates for the given host/service at once.
> > > > > >
> > > > > > Honza
> > > > > >
> > > > > I agree that is a nicer approach.
> > > > >
> > > > > 'revoke_certs' is called from several other places besides just
> > > > > host/service_del. If we want to land this fix Real Soon I'd suggest
> > > > > we either:
> > > > >
> > > > > A) Define function 'revoke_certs_from_cert_find', call it from
> > > > > host/service_del, and leave 'revoke_certs' alone; or
> > > > >
> > > > > B) Land the patch as-is and do a bigger refactor at a later time.
> > > > >
> > > > > What do you think?
> > >
> > Updated patch attached; comments inline.
> >
> > > C) Use cert-find-based revoke_certs() everywhere; use the --certificate
> > > option of cert-find in the other places to get information about specific
> > > certificates.
> > >
> > As discussed on IRC, I have implemented this option. The caveat is
> > that for host/service-mod, we incur call to cert_find for each
> > removed certificate.
>
> It's worth noting that A) and B) suffer from the same caveat.
>
> >
> > > > >
> > > > Updated patch for option (A) is attached.
> > >
> > > 1) Instead of
> > >
> > > if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}:
> > >
> > > use:
> > >
> > > if result['revoked']:
> > >
> > Done.
> >
> > >
> > > 2)
> > >
> > > +if 'cacn' not in cert:
> > > +# cert is known to Dogtag, but CA appears to have been
> > > +# deleted. We cannot revoke this cert via IPA anymore.
> > > +# We could go directly to Dogtag to revoke it, but the
> > > +# issuer's cert should have been revoked so never mind.
> > > +continue
> > >
> > > Or, it could be a cert issued by a 3rd party CA.
> > >
> > I updated to comment to include this.
> >
> > >
> > > 3) host-mod/service-mod do not revoke certs:
> > >
> > > $ ipa cert-request test.csr --principal host/test.example.com
> > > Serial number: 13
> > >
> > > $ ipa cert-show 13
> > > Revoked: False
> > > Owner host: test.example.com
> > >
> > > $ ipa host-mod test.example.com --certificate=
> > >
> > > $ ipa cert-show 13
> > > Revoked: False
> > >
> > Nice find. This was a pre-existing bug: nothing gets revoked when
> > all certs are removed. Here is the fix:
> >
> > -if certs and self.api.Command.ca_is_enabled()['result']:
> > +ca_is_enabled = self.api.Command.ca_is_enabled()['result']
> > +if 'usercertificate' in options and ca_is_enabled:
> > ... revocation code
>
> OK. Since it is a different bug, it should be fixed in a separate patch and
> have a separate ticket.
>
> >
> > Finally, host/service-remove-cert does not revoke the cert because
> > of (I think) a bug in cert-find. If the cert does not exist on a
> > host/service the cert-find cannot find it with --certificate option.
> > Because host/service-remove-cert uses a post_callback to revoke the
> > cert, cert-find doesn't find it thus no revocation occurs.
> >
> > Honza could you check whether this is indeed a bug/limitation of
> > cert-find or is it the smog in Saigon affecting me?
>
> It's a bug - FTFY, <https://github.com/freeipa/freeipa/pull/64>.
>
> Functional ACK. Full ACK once my fix is merged and the host/service-mod is
> split off into a separate patch.
>
To clarify - you want only the fix discussed above in the separate
patch?
Thanks,
Fraser
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Tue, Sep 06, 2016 at 10:19:14AM +0200, Jan Cholasta wrote:
> On 5.9.2016 17:30, Fraser Tweedale wrote:
> > On Mon, Sep 05, 2016 at 11:59:11PM +1000, Fraser Tweedale wrote:
> > > On Tue, Aug 30, 2016 at 10:39:16AM +0200, Jan Cholasta wrote:
> > > > Hi,
> > > >
> > > > On 26.8.2016 07:42, Fraser Tweedale wrote:
> > > > > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221.
> > > > > > It depends on Honza's PR #20
> > > > > > https://github.com/freeipa/freeipa/pull/20.
> > > > > >
> > > > > > Thanks,
> > > > > > Fraser
> > > > > >
> > > > > It does help to attach the patch :)
> > > >
> > > > I think it would be better to call cert-find once per
> > > > host-del/service-del
> > > > with the --host/--service option specified. That way you'll get all
> > > > certificates for the given host/service at once.
> > > >
> > > > Honza
> > > >
> > > I agree that is a nicer approach.
> > >
> > > 'revoke_certs' is called from several other places besides just
> > > host/service_del. If we want to land this fix Real Soon I'd suggest
> > > we either:
> > >
> > > A) Define function 'revoke_certs_from_cert_find', call it from
> > > host/service_del, and leave 'revoke_certs' alone; or
> > >
> > > B) Land the patch as-is and do a bigger refactor at a later time.
> > >
> > > What do you think?
>
Updated patch attached; comments inline.
> C) Use cert-find-based revoke_certs() everywhere; use the --certificate
> option of cert-find in the other places to get information about specific
> certificates.
>
As discussed on IRC, I have implemented this option. The caveat is
that for host/service-mod, we incur call to cert_find for each
removed certificate.
> > >
> > Updated patch for option (A) is attached.
>
> 1) Instead of
>
> if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}:
>
> use:
>
> if result['revoked']:
>
Done.
>
> 2)
>
> +if 'cacn' not in cert:
> +# cert is known to Dogtag, but CA appears to have been
> +# deleted. We cannot revoke this cert via IPA anymore.
> +# We could go directly to Dogtag to revoke it, but the
> +# issuer's cert should have been revoked so never mind.
> +continue
>
> Or, it could be a cert issued by a 3rd party CA.
>
I updated to comment to include this.
>
> 3) host-mod/service-mod do not revoke certs:
>
> $ ipa cert-request test.csr --principal host/test.example.com
> Serial number: 13
>
> $ ipa cert-show 13
> Revoked: False
> Owner host: test.example.com
>
> $ ipa host-mod test.example.com --certificate=
>
> $ ipa cert-show 13
> Revoked: False
>
Nice find. This was a pre-existing bug: nothing gets revoked when
all certs are removed. Here is the fix:
-if certs and self.api.Command.ca_is_enabled()['result']:
+ca_is_enabled = self.api.Command.ca_is_enabled()['result']
+if 'usercertificate' in options and ca_is_enabled:
... revocation code
Finally, host/service-remove-cert does not revoke the cert because
of (I think) a bug in cert-find. If the cert does not exist on a
host/service the cert-find cannot find it with --certificate option.
Because host/service-remove-cert uses a post_callback to revoke the
cert, cert-find doesn't find it thus no revocation occurs.
Honza could you check whether this is indeed a bug/limitation of
cert-find or is it the smog in Saigon affecting me?
Thanks,
Fraser
From 9c829d7ec8ff67dcf814c468c406772bf311c9f8 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 15:31:13 +1000
Subject: [PATCH] Make host/service cert revocation aware of lightweight CAs
Revocation of host/service certs on host/service deletion or other
operations is broken when cert is issued by a lightweight (sub)CA,
causing the delete operation to be aborted. Look up the issuing CA
and pass it to 'cert_revoke' to fix the issue.
Fixes: https://fedorahosted.org/freeipa/ticket/6221
---
ipaserver/plugins/host.py| 23 +
ipaserver/plugins/service.py | 59 ++--
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
index
03c64c637cbba0aee1b6569f3b5dbe20095
Re: [Freeipa-devel] [PATCH] 0102..0105 Better handling for cert-request to disabled CA
On Tue, Aug 30, 2016 at 10:54:32AM +0200, Martin Babinsky wrote:
> On 08/26/2016 04:19 AM, Fraser Tweedale wrote:
> > The attached patches add better handling of cert-request failure due
> > to target CA being disabled (#6260). To do this, rather than go and
> > do extra work in Dogtag that we would depend on, instead I bite the
> > bullet and refactor ra.request_certificate to use the Dogtag REST
> > API, which correctly responds with status 409 in this case.
> >
> > Switching RA to Dogtag REST API is an old ticket (#3437) so these
> > patches address it in part, and show the way forward for the rest of
> > it.
> >
> > These patches don't technically depend on patch 0101 which adds the
> > ca-enable and ca-disable commands, but 0101 may help for testing :)
> >
> > Thanks,
> > Fraser
> >
> >
> >
>
> Hi Fraser,
>
> PATCH 102:
>
> LGTM, but please use the standard ":param " annotations in the docstring for
> `_ssldo` method. It will make out life easier if we decide to use Sphinx or
> similar tool to auto-generate documentation from sources.
>
> You can also add ":raises:" section describing that RemoteRetrieveError is
> raised when use_session is True but the session cookie wasn't acquired. It
> is kind of obvious but it may trip the uninitiated.
>
> PATCH 103:
>
> Due to magical behavior of our public errors, the exception body should look
> like this:
>
> --- a/ipalib/errors.py
> +++ b/ipalib/errors.py
> @@ -1413,10 +1413,7 @@ class HTTPRequestError(RemoteRetrieveError):
> """
>
> errno = 4035
> -
> -def __init__(self, status=None, **kw):
> -assert status is not None
> -super(HTTPRequestError, self).__init__(status=status, **kw)
> +format = _('Request failed with status %(status)s: %(reason)')
>
> The format string will be then automatically be supplied with status and
> reason if you pass them to the constructor ass you already do. The errors
> will be also handled magically (such as status which is None etc.)
>
> PATCH 104:
>
> 1.) please don't use bare except here:
>
> """
> +try:
> +resp_obj = json.loads(http_body)
> +except:
> +raise errors.RemoteRetrieveError(reason=_("Response from CA was
> not valid JSON"))
> """
>
> use 'except Exception' at least.
>
> PATCH 105:
>
> +if e.status == 409: # pylint: disable=E1101
> +raise errors.CertificateOperationError(
> +error=_("CA '%s' is disabled") % ca)
> + else:
> +raise e
> +
>
> please use named errors instead of error codes in pylint annotations:
> # pylint: disable=no-member
>
Thanks for your review, Martin. Updated patches attached; they
address all mentioned issues.
Cheers,
Fraser
From a1aa93ed13a24c9ac946e47ecd49606ebad8bd9e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 08:59:10 +1000
Subject: [PATCH 102/105] Allow Dogtag RestClient to perform requests without
logging in
Currently the Dogtag RestClient '_ssldo' method requires a session
cookie unconditionally, however, not all REST methods require a
session: some do not require authentication at all, and some will
authenticate the agent on the fly.
To avoid unnecessary login/logout requests via the context manager,
add the 'use_session' keyword argument to '_ssldo'. It defaults to
'True' to preserve existing behaviour (session required) but a
caller can set to 'False' to avoid the requirement.
Part of: https://fedorahosted.org/freeipa/ticket/6260
Part of: https://fedorahosted.org/freeipa/ticket/3473
---
ipaserver/plugins/dogtag.py | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index
01e5f1383ee135696a8e968793863ce964025094..f3fb2703f4e1ea688e38cecd02c9acc79213eb40
100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -2071,26 +2071,38 @@ class RestClient(Backend):
)
self.cookie = None
-def _ssldo(self, method, path, headers=None, body=None):
+def _ssldo(self, method, path, headers=None, body=None, use_session=True):
"""
-:param url: The URL to post to.
-:param kw: Keyword arguments to encode into POST body.
+Perform an HTTPS request.
+
+:param method: HTTP method to use
+:param path: Path component. This will *extend* the path defined for
+the class (if any).
+:param headers: Additional headers to include in the request.
+:param body: Requ
Re: [Freeipa-devel] [PATCH] 0101 Add ca-disable and ca-enable commands
On Tue, Aug 30, 2016 at 10:23:10AM +0200, Martin Babinsky wrote:
> On 08/30/2016 10:09 AM, Jan Cholasta wrote:
> > Hi,
> >
> > On 30.8.2016 09:56, Martin Babinsky wrote:
> > > On 08/25/2016 10:25 AM, Fraser Tweedale wrote:
> > > > Hi team,
> > > >
> > > > The attached patch fixes
> > > > https://fedorahosted.org/freeipa/ticket/6257.
> > > >
> > > > The behaviour of cert-request when the CA is disabled is not very
> > > > nice (it reports a server error from Dogtag). The Dogtag REST
> > > > interface gives much better errors so I plan to move to it in a
> > > > later change (which will also address
> > > > https://fedorahosted.org/freeipa/ticket/3473, in part).
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> > > >
> > > >
> > >
> > > HI Fraser,
> > >
> > > I have a couple of comments below:
> > >
> > > 1.)
> > > @@ -25,6 +33,10 @@ EXAMPLES:
> > > ipa ca-add puppet --desc "Puppet" \\
> > > --subject "CN=Puppet CA,O=EXAMPLE.COM"
> > >
> > > + Disable a CA.
> > > +
> > > +ipa ca-disable puppet
> > > +
> > > """)
> > >
> > > You missed an example of `ca-enable` command in the doc string.
> > >
> > > 2.)
> > >
> > > Regarding implementation of ca_enable/disable, I think you can reduce
> > > the amount of code duplication by employing a base class which will look
> > > up the required sub-CA and call the RA backend method required by the
> > > subclass. See the attached untested diff (passes lint) for details.
>
> Looks like I forgot how to OOP while on PTO :) Honza is right, of course,
> see the example code in the attached diff (again not tested, just a quick
> example).
>
Updated patch attached, implemented inheritance suggestion and
expanding plugin help.
Thanks,
Fraser
From 61adc46ec9a19f1044231d193a0d9cdef0adba64 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 25 Aug 2016 17:00:01 +1000
Subject: [PATCH] Add ca-disable and ca-enable commands
We soon plan to revoke certificates upon lightweight CA deletion.
This makes it important to provide a way to prevent a CA from
issuing certificates whilst not deleting and revoking it, and
continuing to allow management of issued certs.
This commit adds the ca-disable and ca-enable commands.
Fixes: https://fedorahosted.org/freeipa/ticket/6257
---
API.txt | 16 +++
VERSION | 4 +--
ipaserver/plugins/ca.py | 66 +++--
ipaserver/plugins/dogtag.py | 6 +
4 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/API.txt b/API.txt
index
5b83bfbd0b457b77e0522ab7d83abfae4df3ebe9..27b64ee143fa4f5f55c1b8a32446f004a8e3bb22
100644
--- a/API.txt
+++ b/API.txt
@@ -465,6 +465,20 @@ option: Str('version?')
output: Output('result', type=[])
output: Output('summary', type=[, ])
output: ListOfPrimaryKeys('value')
+command: ca_disable/1
+args: 1,1,3
+arg: Str('cn', cli_name='name')
+option: Str('version?')
+output: Output('result', type=[])
+output: Output('summary', type=[, ])
+output: PrimaryKey('value')
+command: ca_enable/1
+args: 1,1,3
+arg: Str('cn', cli_name='name')
+option: Str('version?')
+output: Output('result', type=[])
+output: Output('summary', type=[, ])
+output: PrimaryKey('value')
command: ca_find/1
args: 1,11,4
arg: Str('criteria?')
@@ -6249,6 +6263,8 @@ default: batch/1
default: ca/1
default: ca_add/1
default: ca_del/1
+default: ca_disable/1
+default: ca_enable/1
default: ca_find/1
default: ca_is_enabled/1
default: ca_mod/1
diff --git a/VERSION b/VERSION
index
bf8160a5deb1f7a5148ef6833cec318af144b5d7..c6fb1cba2757d919a88093ca3f060f80b2d30621
100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=212
-# Last change: ab: service: add flag to allow S4U2Self
+IPA_API_VERSION_MINOR=213
+# Last change: ftweedal: add ca-disable and ca-enable commands
diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py
index
966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..4d83fe81c951b01d06d3c85d74fe94e24bce0b1f
100644
--- a/ipaserver/plugins/ca.py
+++ b/ipaserver/plugins/ca.py
@@ -2,12 +2,12 @@
# Copyright (C) 2016 FreeIPA Contributors see COPYING for license
#
-from ipalib import api, errors, DNParam, Str
+from ipalib import api, errors, output, DNParam, Str
from ipalib.constants import IPA_CA_CN
from ipalib.
Re: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension
On Tue, Aug 30, 2016 at 08:48:58AM +0200, Jan Cholasta wrote: > On 29.8.2016 07:57, Fraser Tweedale wrote: > > On Fri, Aug 26, 2016 at 10:41:37AM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 22.7.2016 07:18, Fraser Tweedale wrote: > > > > While I was poking around SAN-processing code, I decided to > > > > implement a small enhancement: allowing the subject principal's DN > > > > to appear in SAN. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6112 > > > > > > > > Patch depends on my other patches 0090, 0092, 0093, 0094. > > > > > > I don't think this is how DN SANs are supposed to be handled. For example, > > > see this bit about DN name constraints in RFC 5280 section 4.2.1.10: > > > > > >Restrictions of the form directoryName MUST be applied to the subject > > >field in the certificate (when the certificate includes a non-empty > > >subject field) and to any names of type directoryName in the > > >subjectAltName extension. > > > > > > It would appear to me that DN SANs only provide additional values to the > > > subject name of the certificate and thus should be treated the same way as > > > the subject name. > > > > > > We don't impose any restrictions on subject names with regard to DN of the > > > subject LDAP entry, so I think we should not do it for DN SANs as well. > > > Or, > > > alternatively, we should do it for both. > > > > > I disagree. Supporting an altname containing the LDAP DN is a valid > > use case. There is no need to apply the same rules to Subject DN > > and Directory Name altname > > Nowhere in the RFC is it stated that there is any semantic difference > between the subject name and DN SANs, so I don't see why should we make DN > SANs special. > > > (otherwise, why would the Directory Name > > altname type even exist?). > > To allow multiple subject DNs. > > > There are other possible values but this > > one is trivial to validate so why not? > > I have no issue with validation per se, I just find it very odd that the > code would allow me to request a cert with any LDAP entry DN in subject name > but only one specific LDAP entry DN in DN SAN. > > > > > As for the RFC excerpt, this is about the Name Constraints > > extension. In the unlikely case that a superior certificate has a > > Name Constraints extension that applies to DNs, the way we construct > > the Subject DN is probably the bigger problem ;) > > Yes, this particular excerpt is about name constraints, but I doubt that if > you looked anywhere else, it would say something different about the > relationship of subject name and DN SANs. > RFC 5280 doesn't say anything about the relationship between SDN and DN SAN. All it says is that if there is a name constraint, all the names must satisfy the constraint. A name constraint *could* imply some "shared ancestry" relationships across all DNs on a cert, but this is is not necessarily the case, e.g. if the name constraint only has excludedSubtrees. > > > > Take the feature or leave it (after all, noone has asked for it yet) > > but IMO the usage is valid. > > > > Cheers, > > Fraser > > > > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Fri, Aug 26, 2016 at 10:28:58AM +0200, Jan Cholasta wrote: > On 19.8.2016 13:11, Fraser Tweedale wrote: > > Bump for review. > > > > On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > > > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > > > Please review the attached patch with adds > > > > > > > > > > > --certificate-out and > > > > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a > > > > > > > > > > > bogus file due > > > > > > > > > > > to a bug in Dogtag that will be fixed in this week's > > > > > > > > > > > build. > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the > > > > > > > > > > client side, not > > > > > > > > > > on the server side. > > > > > > > > > > > > > > > > > > > Will option defined on client side be propagated to, and > > > > > > > > > observable > > > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to > > > > > > > > > observe that > > > > > > > > > *-out has been requested and executes additional command(s) > > > > > > > > > on that > > > > > > > > > basis. > > > > > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > > > > so I suppose that's fine. I'll return the cert *and* the chain in > > > > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information > > > > > > > > > > included in summary > > > > > > > > > > (and it definitely should not be multi-line). I would > > > > > > > > > > rather inform the user > > > > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > > > > > > > I was just following the pattern of other commands that write > > > > > > > > > certs, > > > > > > > > > profile config, etc. Apart from consistency with other > > > > > > > > > commands I > > > > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > > > > > > > If you think there is an actual value in informing the user > > > > > > > > > > about > > > > > > > > > > successfully writing the files, please use ipalib.messages > > > > > > > > > > for the job. > > > > > > > > > > >
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Mon, Sep 05, 2016 at 11:59:11PM +1000, Fraser Tweedale wrote:
> On Tue, Aug 30, 2016 at 10:39:16AM +0200, Jan Cholasta wrote:
> > Hi,
> >
> > On 26.8.2016 07:42, Fraser Tweedale wrote:
> > > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote:
> > > > Hi all,
> > > >
> > > > Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221.
> > > > It depends on Honza's PR #20
> > > > https://github.com/freeipa/freeipa/pull/20.
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> > > It does help to attach the patch :)
> >
> > I think it would be better to call cert-find once per host-del/service-del
> > with the --host/--service option specified. That way you'll get all
> > certificates for the given host/service at once.
> >
> > Honza
> >
> I agree that is a nicer approach.
>
> 'revoke_certs' is called from several other places besides just
> host/service_del. If we want to land this fix Real Soon I'd suggest
> we either:
>
> A) Define function 'revoke_certs_from_cert_find', call it from
> host/service_del, and leave 'revoke_certs' alone; or
>
> B) Land the patch as-is and do a bigger refactor at a later time.
>
> What do you think?
>
Updated patch for option (A) is attached.
Thanks,
Fraser
From dacb091292b57608af8adb97adf9a96f1cb34e54 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 15:31:13 +1000
Subject: [PATCH] Make host/service cert revocation aware of lightweight CAs
Revocation of host/service certs on host/service deletion or other
operations is broken when cert is issued by a lightweight (sub)CA,
causing the delete operation to be aborted. Look up the issuing CA
and pass it to 'cert_revoke' to fix the issue.
For host/service deletion, look up all certs at once and pass to an
alternative revocation function that avoids addition calls to
cert_find or cert_show.
Fixes: https://fedorahosted.org/freeipa/ticket/6221
---
ipaserver/plugins/host.py| 11 +++-
ipaserver/plugins/service.py | 66 +---
2 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
index
03c64c637cbba0aee1b6569f3b5dbe200953bff8..891dacd762a57c06ff032e6f262813158c94f9f2
100644
--- a/ipaserver/plugins/host.py
+++ b/ipaserver/plugins/host.py
@@ -42,7 +42,8 @@ from .service import (
validate_realm, normalize_principal, validate_certificate,
set_certificate_attrs, ticket_flags_params, update_krbticketflags,
set_kerberos_attrs, rename_ipaallowedtoperform_from_ldap,
-rename_ipaallowedtoperform_to_ldap, revoke_certs)
+rename_ipaallowedtoperform_to_ldap, revoke_certs,
+revoke_certs_from_cert_find)
from .dns import (dns_container_exists,
add_records_for_host_validation, add_records_for_host,
get_reverse_zone)
@@ -843,12 +844,8 @@ class host_del(LDAPDelete):
)
if self.api.Command.ca_is_enabled()['result']:
-try:
-entry_attrs = ldap.get_entry(dn, ['usercertificate'])
-except errors.NotFound:
-self.obj.handle_not_found(*keys)
-
-revoke_certs(entry_attrs.get('usercertificate', []), self.log)
+certs = self.api.Command.cert_find(host=keys)['result']
+revoke_certs_from_cert_find(certs)
return dn
diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py
index
04d1916fe989a8651bcc4d44f1914c460be1081c..407665fb450e7a8513b42815691d64665b6b2282
100644
--- a/ipaserver/plugins/service.py
+++ b/ipaserver/plugins/service.py
@@ -232,24 +232,73 @@ def revoke_certs(certs, logger=None):
logger.info("Problem decoding certificate: %s" % e)
serial = unicode(x509.get_serial_number(cert, x509.DER))
+issuer = unicode(x509.get_issuer(cert, x509.DER))
try:
-result = api.Command['cert_show'](unicode(serial))['result']
+# search by serial+issuer, not full cert match
+results = api.Command['cert_find'](
+min_serial_number=serial,
+max_serial_number=serial,
+issuer=issuer
+)['result']
+if len(results) == 0:
+# Dogtag doesn't know about the cert therefore
+# we cannot revoke it. Perhaps it was issued by
+# a 3rd-party CA.
+continue
+result = results[0]
except errors.CertificateOperationError:
continue
-if 'revocation_reason' in result:
+if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}:
continue
-if x509.normalize_certificate(result['certif
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Tue, Aug 30, 2016 at 10:39:16AM +0200, Jan Cholasta wrote: > Hi, > > On 26.8.2016 07:42, Fraser Tweedale wrote: > > On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote: > > > Hi all, > > > > > > Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221. > > > It depends on Honza's PR #20 > > > https://github.com/freeipa/freeipa/pull/20. > > > > > > Thanks, > > > Fraser > > > > > It does help to attach the patch :) > > I think it would be better to call cert-find once per host-del/service-del > with the --host/--service option specified. That way you'll get all > certificates for the given host/service at once. > > Honza > I agree that is a nicer approach. 'revoke_certs' is called from several other places besides just host/service_del. If we want to land this fix Real Soon I'd suggest we either: A) Define function 'revoke_certs_from_cert_find', call it from host/service_del, and leave 'revoke_certs' alone; or B) Land the patch as-is and do a bigger refactor at a later time. What do you think? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0014
On Thu, Sep 01, 2016 at 07:37:53PM +0200, Tomas Krizek wrote: > On 09/01/2016 03:58 PM, Florence Blanc-Renaud wrote: > > Hi, > > > > please find attached a patch for ipa-certupdate in CA-less deployment. > > https://fedorahosted.org/freeipa/ticket/6288 > > > > Flo. > > > > > > > The patch is malformed, but you can simply delete the very first character > to fix it. > > Other than that, patch works as expected -> ACK. > The patch malformation is caused by Thunderbird. See [1] for how to configure Thunderbird (and Mutt) to not add the '>'. [1] http://www.freeipa.org/page/Contribute/Patch_Format#Ensuring_correct_transmission_of_patches Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension
On Fri, Aug 26, 2016 at 10:41:37AM +0200, Jan Cholasta wrote: > Hi, > > On 22.7.2016 07:18, Fraser Tweedale wrote: > > While I was poking around SAN-processing code, I decided to > > implement a small enhancement: allowing the subject principal's DN > > to appear in SAN. > > > > https://fedorahosted.org/freeipa/ticket/6112 > > > > Patch depends on my other patches 0090, 0092, 0093, 0094. > > I don't think this is how DN SANs are supposed to be handled. For example, > see this bit about DN name constraints in RFC 5280 section 4.2.1.10: > >Restrictions of the form directoryName MUST be applied to the subject >field in the certificate (when the certificate includes a non-empty >subject field) and to any names of type directoryName in the >subjectAltName extension. > > It would appear to me that DN SANs only provide additional values to the > subject name of the certificate and thus should be treated the same way as > the subject name. > > We don't impose any restrictions on subject names with regard to DN of the > subject LDAP entry, so I think we should not do it for DN SANs as well. Or, > alternatively, we should do it for both. > I disagree. Supporting an altname containing the LDAP DN is a valid use case. There is no need to apply the same rules to Subject DN and Directory Name altname (otherwise, why would the Directory Name altname type even exist?). There are other possible values but this one is trivial to validate so why not? As for the RFC excerpt, this is about the Name Constraints extension. In the unlikely case that a superior certificate has a Name Constraints extension that applies to DNs, the way we construct the Subject DN is probably the bigger problem ;) Take the feature or leave it (after all, noone has asked for it yet) but IMO the usage is valid. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
On Fri, Aug 26, 2016 at 03:37:17PM +1000, Fraser Tweedale wrote:
> Hi all,
>
> Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221.
> It depends on Honza's PR #20
> https://github.com/freeipa/freeipa/pull/20.
>
> Thanks,
> Fraser
>
It does help to attach the patch :)
From 35ab316731d49d503a66d8621b1812a2eb50d180 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 15:31:13 +1000
Subject: [PATCH] Make host/service cert revocation aware of lightweight CAs
Revocation of host/service certs on host/service deletion is broken
when cert is issued by a lightweight (sub)CA, causing the delete
operation to be aborted. Look up the issuing CA and pass it to
'cert_revoke' to fix the issue.
Fixes: https://fedorahosted.org/freeipa/ticket/6221
---
ipaserver/plugins/service.py | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py
index
04d1916fe989a8651bcc4d44f1914c460be1081c..ada5cd1e6f0d289332d77ec651732ba70843ff65
100644
--- a/ipaserver/plugins/service.py
+++ b/ipaserver/plugins/service.py
@@ -232,19 +232,38 @@ def revoke_certs(certs, logger=None):
logger.info("Problem decoding certificate: %s" % e)
serial = unicode(x509.get_serial_number(cert, x509.DER))
+issuer = unicode(x509.get_issuer(cert, x509.DER))
try:
-result = api.Command['cert_show'](unicode(serial))['result']
+# search by serial+issuer, not full cert match
+results = api.Command['cert_find'](
+min_serial_number=serial,
+max_serial_number=serial,
+issuer=issuer
+)['result']
+if len(results) == 0:
+# Dogtag doesn't know about the cert therefore
+# we cannot revoke it. Perhaps it was issued by
+# a 3rd-party CA.
+continue
+result = results[0]
except errors.CertificateOperationError:
continue
-if 'revocation_reason' in result:
+if result['status'] in {'REVOKED', 'REVOKED_EXPIRED'}:
continue
-if x509.normalize_certificate(result['certificate']) != cert:
+if 'cacn' not in result:
+# cert is known to Dogtag, but CA appears to have been
+# deleted. We cannot revoke this cert via IPA anymore.
+# We could go directly to Dogtag to revoke it, but the
+# issuer's cert should have been revoked so never mind.
continue
try:
-api.Command['cert_revoke'](unicode(serial),
- revocation_reason=4)
+api.Command['cert_revoke'](
+serial,
+cacn=result['cacn'],
+revocation_reason=4,
+)
except errors.NotImplementedError:
# some CA's might not implement revoke
pass
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0106 Make host/service cert revocation aware of lightweight CAs
Hi all, Attached patch fixes https://fedorahosted.org/freeipa/ticket/6221. It depends on Honza's PR #20 https://github.com/freeipa/freeipa/pull/20. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0102..0105 Better handling for cert-request to disabled CA
The attached patches add better handling of cert-request failure due
to target CA being disabled (#6260). To do this, rather than go and
do extra work in Dogtag that we would depend on, instead I bite the
bullet and refactor ra.request_certificate to use the Dogtag REST
API, which correctly responds with status 409 in this case.
Switching RA to Dogtag REST API is an old ticket (#3437) so these
patches address it in part, and show the way forward for the rest of
it.
These patches don't technically depend on patch 0101 which adds the
ca-enable and ca-disable commands, but 0101 may help for testing :)
Thanks,
Fraser
From 97501fad9bfe64af076a8c1a65bd732ac265b940 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 08:59:10 +1000
Subject: [PATCH 102/105] Allow Dogtag RestClient to perform requests without
logging in
Currently the Dogtag RestClient '_ssldo' method requires a session
cookie unconditionally, however, not all REST methods require a
session: some do not require authentication at all, and some will
authenticate the agent on the fly.
To avoid unnecessary login/logout requests via the context manager,
add the 'use_session' keyword argument to '_ssldo'. It defaults to
'True' to preserve existing behaviour (session required) but a
caller can set to 'False' to avoid the requirement.
Part of: https://fedorahosted.org/freeipa/ticket/6260
Part of: https://fedorahosted.org/freeipa/ticket/3473
---
ipaserver/plugins/dogtag.py | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index
01e5f1383ee135696a8e968793863ce964025094..ac3fa40f80f7c23ab5dceda5e20a33812ff82a21
100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -2071,26 +2071,40 @@ class RestClient(Backend):
)
self.cookie = None
-def _ssldo(self, method, path, headers=None, body=None):
+def _ssldo(self, method, path, headers=None, body=None, use_session=True):
"""
-:param url: The URL to post to.
-:param kw: Keyword arguments to encode into POST body.
+Perform an HTTPS request.
+
+``method``
+HTTP method to use
+``path``
+Path component. This will *extend* the path defined for
+the class (if any).
+``headers``
+Additional headers to include in the request.
+``body``
+Request body.
+``use_session``
+If ``True``, session cookie is added to request (client
+must be logged in).
+
:return: (http_status, http_headers, http_body)
as (integer, dict, str)
-Perform an HTTPS request
"""
-if self.cookie is None:
-raise errors.RemoteRetrieveError(
-reason=_("REST API is not logged in."))
-
headers = headers or {}
-headers['Cookie'] = self.cookie
+if use_session:
+if self.cookie is None:
+raise errors.RemoteRetrieveError(
+reason=_("REST API is not logged in."))
+headers['Cookie'] = self.cookie
+
+resource = '/ca/rest'
+if self.path is not None:
+resource = os.path.join(resource, self.path)
if path is not None:
-resource = os.path.join('/ca/rest', self.path, path)
-else:
-resource = os.path.join('/ca/rest', self.path)
+resource = os.path.join(resource, path)
# perform main request
status, resp_headers, resp_body = dogtag.https_request(
--
2.5.5
From 5b8c67c2f293cea32f0a492069bab4ce055ed8fa Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 26 Aug 2016 09:04:04 +1000
Subject: [PATCH 103/105] Add HTTPRequestError class
Currently, HTTP requests that respond with status not in the 2xx
range raise RemoteRetrieveError. The exception includes no
information about the response status.
Add the 'HTTPRequestError' class which extends 'RemoteRequestError'
with an attribute for the response status, and update the Dogtag
RestClient to raise the new error.
Part of: https://fedorahosted.org/freeipa/ticket/6260
Part of: https://fedorahosted.org/freeipa/ticket/3473
---
ipalib/errors.py| 13 +
ipaserver/plugins/dogtag.py | 3 ++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/ipalib/errors.py b/ipalib/errors.py
index
4cc4455b0abf7d2b1366e1ce6dbb3762bc551cc6..268376f513e7ba9dbfbffaa103002ae4859ecc47
100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1406,6 +1406,19 @@ class
OperationNotSupportedForPrincipalType(ExecutionError):
'%(operation)s is not supported for %(principal_type)s principals')
+class HTTPRequestError(RemoteRetrieveError):
+"""
+**4035** Raised w
Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names
Thanks for review; rebased and updated patch attached. Only 0090 has substantive changes. Cheers, Fraser On Mon, Aug 22, 2016 at 09:22:08AM +0200, Jan Cholasta wrote: > On 19.8.2016 13:11, Fraser Tweedale wrote: > > Bump for review. > > > > On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote: > > > Thanks for reviews. Rebased and updated patches attached (and one > > > new patch). No substantive changes to 92..94. Patch order is: > > > > > > 92-2, 93-2, 94-2, 98, 90-3 > > > > > > Other comments inline. > > > > > > Thanks, > > > Fraser > > > > > > On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote: > > > > Patch 0092: ACK > > > > > > > > Patch 0093: ACK > > > > > > > > Patch 0094: ACK > > Please fix this PEP8 issue before pushing: > > ./ipaserver/plugins/cert.py:597:17: W503 line break before binary operator > > > Patch 0098: ACK > > > > > > > > > Patch 0090: > > > > > > > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > > > > included in the value and names with complex type other than > > > > KerberosPrincipal are not parsed correctly. The value should include > > > > the OID > > > > and DER blob of the name. > > > > > > > Updated to use "OID:b64(DER)" as the attribute value. > > OK. > > > > > > > > 2) With --all, san_other should be included in the result for all > > > > otherNames, even the known ones, to provide (limited) forward > > > > compatibility. > > > > > > > Done; when --all given, known otherName kinds are included in > > > 'san_other' attribute in addition to their own attribute. > > OK. > > > > > > > > 3) Do we have to support *all* the name types? I mean we could, for the > > > > sake > > > > of completeness, but it might be easier to just keep the few ones we > > > > actually care about (email, DNS name, principal name, UPN and directory > > > > name > > > > in your patch 0095). > > > > > > > Yeah, why not support them all? See also Petr's comments in other > > > branch of thread. > > Works for me, but see Lukáš's reply, I think he has a point. Maybe we can > make a compromise and show only supported name types by default and > everything with --all? > Now only showing DNSName, RFC822Name, DirectoryName, UPN and KRBPrincipalName unless --all is given. > > > > > > > 4) > > > > > > > > +obj.setdefault(attr_name, []).append(unicode(name)) > > > > > > > > The value should not (always) be unicode, but of the type declared by > > > > the > > > > param (unicode or ipapython.kerberos.Principal or > > > > ipapython.dnsutil.DNSName). > > > > > > > I now pass the value to the constructor of whatever type the > > > parameter uses: > > > > > > attr_value = self.params[attr_name].type(name_formatted) > > > obj.setdefault(attr_name, []).append(attr_value) > > OK. > > > 5) san_directoryname should be a DNParam rather than Str. > Fixed, thanks. > > 6) Could we use "Subject " instead of "Subject Alternative Name > ()" for labels? Or something else which is shorter and has the > name type more "visible" than the current form. > No worries. > > 7) The patch needs a rebase. > > > -- > Jan Cholasta From 9dbe4c3cebb1279aefefe3dae9f3da2232d9c12f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale <ftwee...@redhat.com> Date: Thu, 21 Jul 2016 16:27:49 +1000 Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509 GeneralName parsing code is primarily relevant to X.509. An upcoming change will add SAN parsing to the cert-show command, so first move the GeneralName parsing code from ipalib.pkcs10 to ipalib.x509. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/pkcs10.py | 93 ++--- ipalib/x509.py| 114 +- ipaserver/plugins/cert.py | 8 ++-- 3 files changed, 120 insertions(+), 95 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -22,9 +22,10 @@ from __future__ import print_function import sys import base6
[Freeipa-devel] [PATCH] 0100 Track lightweight CAs on replica installation
Hi folks,
Please review attached patch which fixes
https://fedorahosted.org/freeipa/ticket/6019.
Thanks,
Fraser
From 558ec02053154b472b0505e6c2279095f296cb9c Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 23 Aug 2016 16:14:30 +1000
Subject: [PATCH] Track lightweight CAs on replica installation
Add Certmonger tracking requests for lightweight CAs on replica
installation. As part of this change, extract most of the
lightweight CA tracking code out of ipa-certupdate and into
cainstance.
Fixes: https://fedorahosted.org/freeipa/ticket/6019
---
ipaclient/ipa_certupdate.py | 53 +--
ipalib/constants.py | 2 ++
ipaserver/install/cainstance.py | 80 +
3 files changed, 91 insertions(+), 44 deletions(-)
diff --git a/ipaclient/ipa_certupdate.py b/ipaclient/ipa_certupdate.py
index
e59047a2705eb8ccb98b5213c4c8771f55a29bc5..2b33934619aa69e941fb292660ede5f925799142
100644
--- a/ipaclient/ipa_certupdate.py
+++ b/ipaclient/ipa_certupdate.py
@@ -29,10 +29,7 @@ from ipaplatform import services
from ipaplatform.paths import paths
from ipaplatform.tasks import tasks
from ipalib import api, errors, x509, certstore
-from ipalib.constants import IPA_CA_CN
-
-IPA_CA_NICKNAME = 'caSigningCert cert-pki-ca'
-RENEWAL_CA_NAME = 'dogtag-ipa-ca-renew-agent'
+from ipalib.constants import IPA_CA_NICKNAME, RENEWAL_CA_NAME
class CertUpdate(admintool.AdminTool):
command_name = 'ipa-certupdate'
@@ -85,11 +82,8 @@ class CertUpdate(admintool.AdminTool):
certs = certstore.get_ca_certs(ldap, api.env.basedn,
api.env.realm, ca_enabled)
-# find lightweight CAs (on renewal master only)
-lwcas = []
-for ca_obj in api.Command.ca_find()['result']:
-if IPA_CA_CN not in ca_obj['cn']:
-lwcas.append(ca_obj)
+# find lightweight CAs
+lwcas = api.Command.ca_find()['result']
api.Backend.rpcclient.disconnect()
finally:
@@ -98,8 +92,12 @@ class CertUpdate(admintool.AdminTool):
server_fstore = sysrestore.FileStore(paths.SYSRESTORE)
if server_fstore.has_files():
self.update_server(certs)
-for entry in lwcas:
-self.server_track_lightweight_ca(entry)
+try:
+from ipaserver.install import cainstance
+cainstance.add_lightweight_ca_tracking_requests(self.log,
lwcas)
+except Exception as e:
+self.log.exception(
+"Failed to add lightweight CA tracking requests")
self.update_client(certs)
@@ -163,39 +161,6 @@ class CertUpdate(admintool.AdminTool):
self.update_file(paths.CA_CRT, certs)
-def server_track_lightweight_ca(self, entry):
-nickname = "{} {}".format(IPA_CA_NICKNAME, entry['ipacaid'][0])
-criteria = {
-'cert-database': paths.PKI_TOMCAT_ALIAS_DIR,
-'cert-nickname': nickname,
-'ca-name': RENEWAL_CA_NAME,
-}
-request_id = certmonger.get_request_id(criteria)
-if request_id is None:
-try:
-certmonger.dogtag_start_tracking(
-secdir=paths.PKI_TOMCAT_ALIAS_DIR,
-pin=certmonger.get_pin('internal'),
-pinfile=None,
-nickname=nickname,
-ca=RENEWAL_CA_NAME,
-pre_command='stop_pkicad',
-post_command='renew_ca_cert "%s"' % nickname,
-)
-request_id = certmonger.get_request_id(criteria)
-certmonger.modify(request_id, profile='ipaCACertRenewal')
-self.log.debug(
-'Lightweight CA renewal: '
-'added tracking request for "%s"', nickname)
-except RuntimeError as e:
-self.log.error(
-'Lightweight CA renewal: Certmonger failed to '
-'start tracking certificate: %s', e)
-else:
-self.log.debug(
-'Lightweight CA renewal: '
-'already tracking certificate "%s"', nickname)
-
def update_file(self, filename, certs, mode=0o444):
certs = (c[0] for c in certs if c[2] is not False)
try:
diff --git a/ipalib/constants.py b/ipalib/constants.py
index
0574bb3aa457dd79a6d64f6b8a6b57161d32da92..d5b918c49d695c5a15bee576d88902700743e263
100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -273,3 +273,5 @@ CA_SUFFIX_NAME = 'ca'
PKI_GSSAPI_SERVICE_NAME = 'dogtag'
IPA_CA_CN = u'ipa'
IPA_CA_RECORD = "ipa-ca"
+IPA_CA_NICKNAME = 'caSigningCert cert-pki-ca'
+RENEWAL_CA_NAME = 'dogtag-ipa-ca-renew-agent'
diff --git a/ipaserver/install/cainstance.py b/ipaserver/ins
Re: [Freeipa-devel] invoking ipa-certupdate from within installer
On Mon, Aug 22, 2016 at 10:00:57AM +0200, Jan Cholasta wrote: > Hi, > > On 22.8.2016 09:37, Fraser Tweedale wrote: > > #6019 requires adding tracking requests for existing lightweight CAs > > as part of replica installation. ipa-certupdate has logic to do > > this. > > > > Before I go ahead and implement, there are a few approaches I want > > to mention and seek feedback from team members before I commit to > > one. > > > > 1. invoke ipa-certupdate as a subprocess, from > > CAInstance.configure_replica. This is the simplest approach. Not > > much else to say about it, really :) > > > > 2. invoke ipa-certupdate's main() from the installer. This is > > slightly more work because currently it would fail due to API > > already having been initialised. > > > > 3. extract all logic for adding tracking requests such that it can > > be invoked separately; then refactor ipa-certupdate to call it as > > well as calling it from CAInstance.configure_replica. This is the > > most work. > > > > I lean towards (1) or (3). If you wish it to be done a certain way > > say your piece. > > (4) Extract the relevant code from ipa-certupdate into a separate function > and call it from CAInstance.configure_replica(). > > I would not go with (1) or (2) because it does more than track the certs. I > would also not go with (3) because it requires extensive changes not > suitable for 4.4. > (4) is exactly what I meant in (3) - (I was too vague). (3/4) it is. Thanks for input. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] invoking ipa-certupdate from within installer
#6019 requires adding tracking requests for existing lightweight CAs as part of replica installation. ipa-certupdate has logic to do this. Before I go ahead and implement, there are a few approaches I want to mention and seek feedback from team members before I commit to one. 1. invoke ipa-certupdate as a subprocess, from CAInstance.configure_replica. This is the simplest approach. Not much else to say about it, really :) 2. invoke ipa-certupdate's main() from the installer. This is slightly more work because currently it would fail due to API already having been initialised. 3. extract all logic for adding tracking requests such that it can be invoked separately; then refactor ipa-certupdate to call it as well as calling it from CAInstance.configure_replica. This is the most work. I lean towards (1) or (3). If you wish it to be done a certain way say your piece. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0091 Allow full customisability of CA subject name
On Fri, Aug 19, 2016 at 08:09:33PM +1000, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 10:54:25PM +1000, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > > > On 19.7.2016 12:05, Jan Cholasta wrote: > > > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > > > The attached patch is a work in progress for > > > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > > > > > I am sharing now to make the approach clear and solicit > > > > > > > > feedback. > > > > > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > > > without CA) and CA-replica install (all hosts running > > > > > > > > master+patch). > > > > > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install > > > > > > > > on a > > > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but > > > > > > > > let > > > > > > > > me know your questions and comments. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Fraser > > > > > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > > > additional > > > > > > magic around --subject, I would rather add a new separate option for > > > > > > specifying the CA subject name (I think --ca-subject, for > > > > > > consistency > > > > > > with > > > > > > --ca-signing-algorithm). > > > > > > > > > > > The current situation - the --subject argument which specifies the > > > > > not the subject but the subject base, is confusing enough (to say > > > > > nothing of the limitations that give rise to the RFE). > > > > > > > > > > Retaining --subject for specifying the subject base and adding > > > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > > > line in terms of the RFE, but does not make the installer less > > > > > confusing. This is why I made --subject accept the full subject DN, > > > > > with provisions to retain existing behaviour. > > > > > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > > > base (I am not against it), let's bite the bullet and name arguments > > > > > accordingly. --subject should be used to specify full Subject DN, > > > > > --subject-base (or similar) for specifying subject base. > > > > > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > > > whose subject name that is (the CA's). I agree that --subject should be > > > > deprecated and replaced with --subject-base. > > > > > > > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > > > or both are specified; let's resolve the question or renaming / > > > > > changing meaning of arguments first). > > > > > > > > > > > > > > > > By specifying the option you would override the default > > > > > > "CN=Certificate > > > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not > > > > > > used, > > > > > > additional validation would be done to make sure the subject name > > > > > > meets > > > > > > Dogtag's expectations. Actually, it might make sense to always do > > > >
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
Bump for review. On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > Please review the attached patch with adds --certificate-out > > > > > > > > > and > > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus > > > > > > > > > file due > > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the > > > > > > > > client side, not > > > > > > > > on the server side. > > > > > > > > > > > > > > > Will option defined on client side be propagated to, and > > > > > > > observable > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe > > > > > > > that > > > > > > > *-out has been requested and executes additional command(s) on > > > > > > > that > > > > > > > basis. > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > > so I suppose that's fine. I'll return the cert *and* the chain in > > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information > > > > > > > > included in summary > > > > > > > > (and it definitely should not be multi-line). I would rather > > > > > > > > inform the user > > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > > > I was just following the pattern of other commands that write > > > > > > > certs, > > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > > > If you think there is an actual value in informing the user > > > > > > > > about > > > > > > > > successfully writing the files, please use ipalib.messages for > > > > > > > > the job. > > > > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 > > > > > > > > would be > > > > > > > > concatenated PEM, as that's the most commonly used format in > > > > > > > > IPA (in > > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > > > True, which is exactly why I think we
[Freeipa-devel] [PATCH] 0084 cert-revoke: fix permission check bypass
This patch fixes CVE-2016-5404. Versions for master, ipa-4-3 and
ipa-4-2 branches are attached.
Thanks,
Fraser
From 61590c223aa51668b3f661fc91bc35f2dfae8ae6 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 30 Jun 2016 10:21:01 +1000
Subject: [PATCH] cert-revoke: fix permission check bypass (CVE-2016-5404)
The 'cert_revoke' command checks the 'revoke certificate'
permission, however, if an ACIError is raised, it then invokes the
'cert_show' command. The rational was to re-use a "host manages
certificate" check that is part of the 'cert_show' command, however,
it is sufficient that 'cert_show' executes successfully for
'cert_revoke' to recover from the ACIError continue. Therefore,
anyone with 'retrieve certificate' permission can revoke *any*
certificate and cause various kinds of DoS.
Fix the problem by extracting the "host manages certificate" check
to its own method and explicitly calling it from 'cert_revoke'.
Fixes: https://fedorahosted.org/freeipa/ticket/6232
---
ipaserver/plugins/cert.py | 60 +--
1 file changed, 32 insertions(+), 28 deletions(-)
diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py
index
b8df074a186ca91daa8e8f5e725724ea7bc5a663..6dd9f6ffcdcd9d051d50d912996fea2104d71dff
100644
--- a/ipaserver/plugins/cert.py
+++ b/ipaserver/plugins/cert.py
@@ -242,6 +242,24 @@ def validate_certificate(value):
return x509.validate_certificate(value, x509.DER)
+def bind_principal_can_manage_cert(cert):
+"""Check that the bind principal can manage the given cert.
+
+``cert``
+An NSS certificate object.
+
+"""
+bind_principal = kerberos.Principal(getattr(context, 'principal'))
+if not bind_principal.is_host:
+return False
+
+hostname = bind_principal.hostname
+
+# If we have a hostname we want to verify that the subject
+# of the certificate matches it.
+return hostname == cert.subject.common_name #pylint: disable=E1101
+
+
class BaseCertObject(Object):
takes_params = (
Bytes(
@@ -744,18 +762,6 @@ class cert_show(Retrieve, CertMethod, VirtualCommand):
def execute(self, serial_number, all=False, raw=False, no_members=False,
**options):
ca_enabled_check()
-hostname = None
-try:
-self.check_access()
-except errors.ACIError as acierr:
-self.debug("Not granted by ACI to retrieve certificate, looking at
principal")
-bind_principal = kerberos.Principal(getattr(context, 'principal'))
-if not bind_principal.is_host:
-raise acierr
-hostname = bind_principal.hostname
-
-ca_obj = api.Command.ca_show(options['cacn'])['result']
-issuer_dn = ca_obj['ipacasubjectdn'][0]
# Dogtag lightweight CAs have shared serial number domain, so
# we don't tell Dogtag the issuer (but we check the cert after).
@@ -763,7 +769,15 @@ class cert_show(Retrieve, CertMethod, VirtualCommand):
result = self.Backend.ra.get_certificate(str(serial_number))
cert = x509.load_certificate(result['certificate'])
-if DN(unicode(cert.issuer)) != DN(issuer_dn):
+try:
+self.check_access()
+except errors.ACIError as acierr:
+self.debug("Not granted by ACI to retrieve certificate, looking at
principal")
+if not bind_principal_can_manage_cert(cert):
+raise acierr # pylint: disable=E0702
+
+ca_obj = api.Command.ca_show(options['cacn'])['result']
+if DN(unicode(cert.issuer)) != DN(ca_obj['ipacasubjectdn'][0]):
# DN of cert differs from what we requested
raise errors.NotFound(
reason=_("Certificate with serial number %(serial)s "
@@ -789,12 +803,6 @@ class cert_show(Retrieve, CertMethod, VirtualCommand):
result['revoked'] = ('revocation_reason' in result)
self.obj._fill_owners(result)
-if hostname:
-# If we have a hostname we want to verify that the subject
-# of the certificate matches it, otherwise raise an error
-if hostname != cert.subject.common_name:#pylint: disable=E1101
-raise acierr
-
return dict(result=result, value=pkey_to_value(serial_number, options))
@@ -819,22 +827,18 @@ class cert_revoke(PKQuery, CertMethod, VirtualCommand):
# Make sure that the cert specified by issuer+serial exists.
# Will raise NotFound if it does not.
-cert_show_options = dict(cacn=kw['cacn'])
-api.Command.cert_show(unicode(serial_number), **cert_show_options)
+resp = api.Command.cert_show(unicode(serial_number), cacn=kw['cacn'])
-hostname = None
try:
self.check_access()
except errors.ACIError as acierr:
Re: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name
On Mon, Aug 15, 2016 at 10:54:25PM +1000, Fraser Tweedale wrote: > On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > > On 19.7.2016 12:05, Jan Cholasta wrote: > > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > > Hi, > > > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > > The attached patch is a work in progress for > > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > > without CA) and CA-replica install (all hosts running > > > > > > > master+patch). > > > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install on a > > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but > > > > > > > let > > > > > > > me know your questions and comments. > > > > > > > > > > > > > > Thanks, > > > > > > > Fraser > > > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > > additional > > > > > magic around --subject, I would rather add a new separate option for > > > > > specifying the CA subject name (I think --ca-subject, for consistency > > > > > with > > > > > --ca-signing-algorithm). > > > > > > > > > The current situation - the --subject argument which specifies the > > > > not the subject but the subject base, is confusing enough (to say > > > > nothing of the limitations that give rise to the RFE). > > > > > > > > Retaining --subject for specifying the subject base and adding > > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > > line in terms of the RFE, but does not make the installer less > > > > confusing. This is why I made --subject accept the full subject DN, > > > > with provisions to retain existing behaviour. > > > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > > base (I am not against it), let's bite the bullet and name arguments > > > > accordingly. --subject should be used to specify full Subject DN, > > > > --subject-base (or similar) for specifying subject base. > > > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > > whose subject name that is (the CA's). I agree that --subject should be > > > deprecated and replaced with --subject-base. > > > > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > > or both are specified; let's resolve the question or renaming / > > > > changing meaning of arguments first). > > > > > > > > > > > > > By specifying the option you would override the default > > > > > "CN=Certificate > > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > > > > > additional validation would be done to make sure the subject name > > > > > meets > > > > > Dogtag's expectations. Actually, it might make sense to always do the > > > > > additional validation, to be able to print a warning that if a > > > > > Dogtag-incompatible subject name is used, it won't be possible to > > > > > change the > > > > > CA cert chaining from externally signed to self-signed later. > > > > > > > > > > Honza > > > > Bump, any update on this? > > > I have an updated patch that fixes some issues Sebastian encountered > in testing, but I've not yet tackled the main change requested by > Honza (in brief: adding --ca-subject for specifying that, adding > --subject-base for specifying that, and deprecating --subject; > Sebastian, see discussion above and feel free to give your > thoughts). I expect I'll get back onto this work within the next > few days. > Update: I've got an updated version of patch almost ready for review, but I'm still ironing out some wrinkles in replica installation. Expect to be able to send it Monday or Tuesday for review. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > On 16.8.2016 07:24, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file > > > > > > > > due > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client > > > > > > > side, not > > > > > > > on the server side. > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > basis. > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > I don't think that's an issue in a -show command. > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > so I suppose that's fine. I'll return the cert *and* the chain in > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included > > > > > > > in summary > > > > > > > (and it definitely should not be multi-line). I would rather > > > > > > > inform the user > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > successfully writing the files, please use ipalib.messages for > > > > > > > the job. > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 > > > > > > > would be > > > > > > > concatenated PEM, as that's the most commonly used format in IPA > > > > > > > (in > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > True, which is exactly why I think we should at least be > > > > > self-consistent and > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > header). > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > on the server. Do we have a good way of doing this without exec'ing > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > to do the conversion on the server? python-nss does
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > On 16.8.2016 07:24, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file > > > > > > > > due > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client > > > > > > > side, not > > > > > > > on the server side. > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > basis. > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > I don't think that's an issue in a -show command. > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > so I suppose that's fine. I'll return the cert *and* the chain in > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included > > > > > > > in summary > > > > > > > (and it definitely should not be multi-line). I would rather > > > > > > > inform the user > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > successfully writing the files, please use ipalib.messages for > > > > > > > the job. > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 > > > > > > > would be > > > > > > > concatenated PEM, as that's the most commonly used format in IPA > > > > > > > (in > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > True, which is exactly why I think we should at least be > > > > > self-consistent and > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > header). > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > on the server. Do we have a good way of doing this without exec'ing > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > to do the conversion on the server? python-nss does
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > On 9.8.2016 16:47, Fraser Tweedale wrote: > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > Hi, > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > 1) The client-side *-out options should be defined on the client > > > > > side, not > > > > > on the server side. > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > *-out has been requested and executes additional command(s) on that > > > > basis. > > > > > > Is there a reason not to *always* return the certs? > > > > > We hit Dogtag to retrieve them. > > I don't think that's an issue in a -show command. > cert_show is invoked by other commands (cert_find*, cert_show, cert_request, cert_status, ca_del) but these all hit Dogtag anyway so I suppose that's fine. I'll return the cert *and* the chain in separate attributes, unconditionally. > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in > > > > > summary > > > > > (and it definitely should not be multi-line). I would rather inform > > > > > the user > > > > > via an error message when unable to write the files. > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > profile config, etc. Apart from consistency with other commands I > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > If you think there is an actual value in informing the user about > > > > > successfully writing the files, please use ipalib.messages for the > > > > > job. > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > True, which is exactly why I think we should at least be self-consistent > > > and > > > use concatenated PEM (and multi-value DER over the wire). > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > header). > > > > If we want list-of-PEMs between server and client we have to convert > > on the server. Do we have a good way of doing this without exec'ing > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > to do the conversion on the server? python-nss does not have PKCS7 > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > the sake of pushing bits as list-of-PEMs. > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > For example, if we added a call to retrieve external CA chain using certs > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > PKCS#7 if it was our cert chain format of choice. > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > we can use an approach similar to our DNSSEC code and use python-cffi to > call libcrypto's PKCS#7 conversion routines instead. > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to exec `openssl' to do the job :) I will transmit DER-encoded PKCS #7 object on the wire; we cannot used multi-valued DER attribute because order is important. Client will convert
Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation
On Mon, Aug 15, 2016 at 03:58:40PM +0200, Petr Spacek wrote: > On 15.8.2016 15:54, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: > >> On 15.8.2016 15:16, Fraser Tweedale wrote: > >>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > >>>> On 2.8.2016 05:57, Fraser Tweedale wrote: > >>>>>>> Hah! This is what I get for thinking I know what the output has to > >>>>>>> look > >>>>>>> like, and not testing all the way through to requesting the cert. I'll > >>>>>>> change the profile to generate a subject with CN= instead of UID=. > >>>>>>> Updated > >>>>>>> patch is attached. Unfortunately these rules are only updated at > >>>>>>> ipa-server-install time, so if you'd like to fix it without > >>>>>>> reinstalling: > >>>>>>> > >>>>> (Tangential commentary...) Yeah, currently cert-request demands the > >>>>> CN. There is a design to relax the requirement to handle empty > >>>>> subject names (look at SAN only). IMO it would make sense to accept > >>>>> other "obvious" mappings in Subject DN like accepting UID instead of > >>>>> CN for user subjects, but that would be a separate RFE. Noone has > >>>>> actually asked for it yet :) > >>>> > >>>> Side-note: > >>>> I thought that subject format is enforced by certificate profile on > >>>> server. > >>>> Am I wrong? > >>>> > >>> You are right - what I suggested above would (today) require a > >>> custom profile. > >> > >> Sooo... > >> can we just relax existing profiles not to require CN= but accept SAN-only > >> CSRs? > >> > >> :-) > >> > > That is absolutely going to happen as part of > > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) > > Good! > > Is it still targeting 4.4.x? > It's not going to make it. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation
On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote: > On 15.8.2016 15:16, Fraser Tweedale wrote: > > On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > >> On 2.8.2016 05:57, Fraser Tweedale wrote: > >>>>> Hah! This is what I get for thinking I know what the output has to look > >>>>> like, and not testing all the way through to requesting the cert. I'll > >>>>> change the profile to generate a subject with CN= instead of UID=. > >>>>> Updated > >>>>> patch is attached. Unfortunately these rules are only updated at > >>>>> ipa-server-install time, so if you'd like to fix it without > >>>>> reinstalling: > >>>>> > >>> (Tangential commentary...) Yeah, currently cert-request demands the > >>> CN. There is a design to relax the requirement to handle empty > >>> subject names (look at SAN only). IMO it would make sense to accept > >>> other "obvious" mappings in Subject DN like accepting UID instead of > >>> CN for user subjects, but that would be a separate RFE. Noone has > >>> actually asked for it yet :) > >> > >> Side-note: > >> I thought that subject format is enforced by certificate profile on server. > >> Am I wrong? > >> > > You are right - what I suggested above would (today) require a > > custom profile. > > Sooo... > can we just relax existing profiles not to require CN= but accept SAN-only > CSRs? > > :-) > That is absolutely going to happen as part of http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation
On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote: > On 2.8.2016 05:57, Fraser Tweedale wrote: > >> > Hah! This is what I get for thinking I know what the output has to look > >> > like, and not testing all the way through to requesting the cert. I'll > >> > change the profile to generate a subject with CN= instead of UID=. > >> > Updated > >> > patch is attached. Unfortunately these rules are only updated at > >> > ipa-server-install time, so if you'd like to fix it without reinstalling: > >> > > > (Tangential commentary...) Yeah, currently cert-request demands the > > CN. There is a design to relax the requirement to handle empty > > subject names (look at SAN only). IMO it would make sense to accept > > other "obvious" mappings in Subject DN like accepting UID instead of > > CN for user subjects, but that would be a separate RFE. Noone has > > actually asked for it yet :) > > Side-note: > I thought that subject format is enforced by certificate profile on server. > Am I wrong? > You are right - what I suggested above would (today) require a custom profile. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names
On Mon, Aug 15, 2016 at 07:48:22AM +0200, Jan Cholasta wrote: > On 12.8.2016 18:57, Petr Spacek wrote: > > On 12.8.2016 11:33, Jan Cholasta wrote: > > > On 4.8.2016 18:18, Petr Vobornik wrote: > > > > On 07/22/2016 07:13 AM, Fraser Tweedale wrote: > > > > > On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 14.7.2016 13:44, Fraser Tweedale wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > The attached patch includes SANs in cert-show output. If you have > > > > > > > certs with esoteric altnames (especially any that are more than > > > > > > > just > > > > > > > ASN.1 string types), please test with those certs. > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6022 > > > > > > > > > > > > I think it would be better to have a separate attribute for each > > > > > > supported > > > > > > SAN type rather than cramming everything into subject_alt_name. > > > > > > That way if > > > > > > you care only about a single specific type you won't have to go > > > > > > through all > > > > > > the values and parse them. Also it would allow you to use param > > > > > > types > > > > > > appropriate to the SAN types (DNSNameParam for DNS names, Principal > > > > > > for > > > > > > principal names, etc.) > > > > > > > > > > > > Nitpick: please don't mix moving existing stuff and adding new > > > > > > stuff in a > > > > > > single patch. > > > > > > > > > > > Updated patches attached. > > > > > > > > > > Patches 0092..0094 are refactors and bugfixes. > > > > > Patch 0090-2 is the main feature (depends on 0092..0094). > > > > > > > > > > Thanks, > > > > > Fraser > > > > > > > > > > > > > bump for review > > > > > > Patch 0092: ACK > > > > > > Patch 0093: ACK > > > > > > Patch 0094: ACK > > > > > > Patch 0090: > > > > > > 1) Generic otherNames (san_other) do not work correctly. The OID is not > > > included in the value and names with complex type other than > > > KerberosPrincipal > > > are not parsed correctly. The value should include the OID and DER blob > > > of the > > > name. > > > > > > 2) With --all, san_other should be included in the result for all > > > otherNames, > > > even the known ones, to provide (limited) forward compatibility. > > > > > > 3) Do we have to support *all* the name types? I mean we could, for the > > > sake > > > of completeness, but it might be easier to just keep the few ones we > > > actually > > > care about (email, DNS name, principal name, UPN and directory name in > > > your > > > patch 0095). > > > > As far as I remember this reasoning usually comes back to bite us into butt. > > > > - "Implement only this subset, nobody else needs the other the of ... > > (whatever, e.g. DNS record type)." > > - "Yes my lord." > > > > Two months later: > > > > - "We need to support for XYZ. It was (already) late yesterday!" > > > > :-) > > Care to give a concrete example of when this actually happened? Because IIRC > this happened once or twice, not "usually". > > Anyway, I'm fine with whatever, my point was that additional effort needs to > be put in to support "everything" and even then, we wouldn't actually > support everything (two months later: "we need to support extension XYZ!"). > Sure, but in this case it was minimal additional effort to support even the esoteric name types - it is only for display after all; if an uncommon altname is (somehow) there we can display it. > (FWIW, I think it would be more useful to add support for Basic constraints > rather than X.400 SANs.) > I can only agree, and say: another RFE for another day :) > > > > Petr^2 Spacek > > > > > > > > 4) > > > > > > +obj.setdefault(attr_name, []).append(unicode(name)) > > > > > > The value should not (always) be unicode, but of the type declared by the > > > param (unicode or ipapython.kerberos.Principal or > > > ipapython.dnsutil.DNSName). > > > > > -- > Jan Cholasta > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name
On Mon, Aug 15, 2016 at 02:08:54PM +0200, Jan Cholasta wrote: > On 19.7.2016 12:05, Jan Cholasta wrote: > > On 19.7.2016 11:54, Fraser Tweedale wrote: > > > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > > > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > > > > The attached patch is a work in progress for > > > > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > > > > > > > It has been tested for server install, replica install (with and > > > > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > > > > > > > Migration from earlier versions and server/replica/CA install on a > > > > > > CA-less deployment are not yet tested; these will be tested over > > > > > > coming days and patch will be tweaked as necessary. > > > > > > > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > > > > me know your questions and comments. > > > > > > > > > > > > Thanks, > > > > > > Fraser > > > > > > > > > > > It does help to attach the patch, of course ^_^ > > > > > > > > IMO explicit is better than implicit, so instead of introducing > > > > additional > > > > magic around --subject, I would rather add a new separate option for > > > > specifying the CA subject name (I think --ca-subject, for consistency > > > > with > > > > --ca-signing-algorithm). > > > > > > > The current situation - the --subject argument which specifies the > > > not the subject but the subject base, is confusing enough (to say > > > nothing of the limitations that give rise to the RFE). > > > > > > Retaining --subject for specifying the subject base and adding > > > --ca-subject for specifying the *actual* subject DN gets us over the > > > line in terms of the RFE, but does not make the installer less > > > confusing. This is why I made --subject accept the full subject DN, > > > with provisions to retain existing behaviour. > > > > > > IMO if we want to have separate arguments for subject DN and subject > > > base (I am not against it), let's bite the bullet and name arguments > > > accordingly. --subject should be used to specify full Subject DN, > > > --subject-base (or similar) for specifying subject base. > > > > IMHO --ca-subject is better than --subject, because it is more explicit > > whose subject name that is (the CA's). I agree that --subject should be > > deprecated and replaced with --subject-base. > > > > > > > > (I intentionally defer discussion of specific behaviour if one, none > > > or both are specified; let's resolve the question or renaming / > > > changing meaning of arguments first). > > > > > > > > > > By specifying the option you would override the default "CN=Certificate > > > > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > > > > additional validation would be done to make sure the subject name meets > > > > Dogtag's expectations. Actually, it might make sense to always do the > > > > additional validation, to be able to print a warning that if a > > > > Dogtag-incompatible subject name is used, it won't be possible to > > > > change the > > > > CA cert chaining from externally signed to self-signed later. > > > > > > > > Honza > > Bump, any update on this? > I have an updated patch that fixes some issues Sebastian encountered in testing, but I've not yet tackled the main change requested by Honza (in brief: adding --ca-subject for specifying that, adding --subject-base for specifying that, and deprecating --subject; Sebastian, see discussion above and feel free to give your thoughts). I expect I'll get back onto this work within the next few days. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names
Thanks for reviews. Rebased and updated patches attached (and one
new patch). No substantive changes to 92..94. Patch order is:
92-2, 93-2, 94-2, 98, 90-3
Other comments inline.
Thanks,
Fraser
On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote:
> Patch 0092: ACK
>
> Patch 0093: ACK
>
> Patch 0094: ACK
>
> Patch 0090:
>
> 1) Generic otherNames (san_other) do not work correctly. The OID is not
> included in the value and names with complex type other than
> KerberosPrincipal are not parsed correctly. The value should include the OID
> and DER blob of the name.
>
Updated to use "OID:b64(DER)" as the attribute value.
> 2) With --all, san_other should be included in the result for all
> otherNames, even the known ones, to provide (limited) forward compatibility.
>
Done; when --all given, known otherName kinds are included in
'san_other' attribute in addition to their own attribute.
> 3) Do we have to support *all* the name types? I mean we could, for the sake
> of completeness, but it might be easier to just keep the few ones we
> actually care about (email, DNS name, principal name, UPN and directory name
> in your patch 0095).
>
Yeah, why not support them all? See also Petr's comments in other
branch of thread.
> 4)
>
> +obj.setdefault(attr_name, []).append(unicode(name))
>
> The value should not (always) be unicode, but of the type declared by the
> param (unicode or ipapython.kerberos.Principal or
> ipapython.dnsutil.DNSName).
>
I now pass the value to the constructor of whatever type the
parameter uses:
attr_value = self.params[attr_name].type(name_formatted)
obj.setdefault(attr_name, []).append(attr_value)
From 17e5515ab0eeb92d87091eb00a26dcf358060dba Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 21 Jul 2016 16:27:49 +1000
Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509
GeneralName parsing code is primarily relevant to X.509. An
upcoming change will add SAN parsing to the cert-show command, so
first move the GeneralName parsing code from ipalib.pkcs10 to
ipalib.x509.
Part of: https://fedorahosted.org/freeipa/ticket/6022
---
ipalib/pkcs10.py | 93 ++---
ipalib/x509.py| 114 +-
ipaserver/plugins/cert.py | 8 ++--
3 files changed, 120 insertions(+), 95 deletions(-)
diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py
index
e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c
100644
--- a/ipalib/pkcs10.py
+++ b/ipalib/pkcs10.py
@@ -22,9 +22,10 @@ from __future__ import print_function
import sys
import base64
import nss.nss as nss
-from pyasn1.type import univ, char, namedtype, tag
+from pyasn1.type import univ, namedtype, tag
from pyasn1.codec.der import decoder
import six
+from ipalib import x509
if six.PY3:
unicode = str
@@ -32,11 +33,6 @@ if six.PY3:
PEM = 0
DER = 1
-SAN_DNSNAME = 'DNS name'
-SAN_RFC822NAME = 'RFC822 Name'
-SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)'
-SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)'
-
def get_subject(csr, datatype=PEM):
"""
Given a CSR return the subject value.
@@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM):
return tuple(get_prefixed_oid_str(ext)[4:]
for ext in request.extensions)
-class _PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('name-type', univ.Integer().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('name-string',
univ.SequenceOf(char.GeneralString()).subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-class _KRB5PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('realm', char.GeneralString().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('principalName', _PrincipalName().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-def _decode_krb5principalname(data):
-principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0]
-realm = (str(principal['realm']).replace('\\', '')
-.replace('@', '\\@'))
-name = principal['principalName']['name-string']
-name = '/'.join(str(n).replace('\\', '')
- .replace('/', '\\/')
- .replace('@', '\\@') for n in name)
-name = '%s@%s' % (name, realm)
-return name
-
-class _AnotherName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('type-id'
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > On 8.8.2016 09:06, Fraser Tweedale wrote: > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > Please review the attached patch with adds --certificate-out and > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > on the server side. > > > > > Will option defined on client side be propagated to, and observable > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > *-out has been requested and executes additional command(s) on that > > basis. > > Is there a reason not to *always* return the certs? > We hit Dogtag to retrieve them. > > > > > > > > 2) I don't think there should be additional information included in > > > summary > > > (and it definitely should not be multi-line). I would rather inform the > > > user > > > via an error message when unable to write the files. > > > > > I was just following the pattern of other commands that write certs, > > profile config, etc. Apart from consistency with other commands I > > agree that there is no need to have it. So I will remove it. > > > > > If you think there is an actual value in informing the user about > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > installers, there are no cert chains in API commands ATM). > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > or concatenated PEMs, but sometimes they must be concatenated > > forward, and othertimes backwards. There is no one size fits all. > > True, which is exactly why I think we should at least be self-consistent and > use concatenated PEM (and multi-value DER over the wire). > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept header). If we want list-of-PEMs between server and client we have to convert on the server. Do we have a good way of doing this without exec'ing `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' to do the conversion on the server? python-nss does not have PKCS7 functions and I am not keen on adding a pyasn1 PKCS7 parser just for the sake of pushing bits as list-of-PEMs. FWIW, man pages and code suggest that PKCS #7 is accepted in installer, etc. > > We can add an option to control the format later, but for now, > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > themselves. > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > so I'm afraid the worst case would happen virtually always. > If you're OK with invoking OpenSSL on the client to convert PKCS #7 to list-of-PEMs (similar to what is done in ipapython.certdb.NSSDatabase) then we can have the client perform the conversion. > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > common wire format in other API commands. > > > > > OK. > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > separate? For end-entity certs it makes sense to separate the cert from > > > the > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > login to certs issued by VPN sub-CA) then you often just want the > > cert. The chain option does subsume it, at cost of more work for > > administrators with this use case. I think it makes sense to keep > > both options. > > Does it? From what you described above, you either want just the sub-CA > cert, or the full chain including the sub-CA cert, in which case it might > make more sense to have a single --out option and a --chain flag. > How about --certificate-out which defaults to single cert, but does chain (as list-of-PEMs) when --chain flag given. Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more `--out' options. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > Hi, > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > Please review the attached patch with adds --certificate-out and > > --certificate-chain-out options to `ca-show' command. > > > > Note that --certificate-chain-out currently writes a bogus file due > > to a bug in Dogtag that will be fixed in this week's build. > > > > https://fedorahosted.org/freeipa/ticket/6178 > > 1) The client-side *-out options should be defined on the client side, not > on the server side. > Will option defined on client side be propagated to, and observable in the ipaserver plugin? The ipaserver plugin needs to observe that *-out has been requested and executes additional command(s) on that basis. > > 2) I don't think there should be additional information included in summary > (and it definitely should not be multi-line). I would rather inform the user > via an error message when unable to write the files. > I was just following the pattern of other commands that write certs, profile config, etc. Apart from consistency with other commands I agree that there is no need to have it. So I will remove it. > If you think there is an actual value in informing the user about > successfully writing the files, please use ipalib.messages for the job. > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > concatenated PEM, as that's the most commonly used format in IPA (in > installers, there are no cert chains in API commands ATM). > Sure, but the main use case isn't IPA. Other apps require PKCS #7 or concatenated PEMs, but sometimes they must be concatenated forward, and othertimes backwards. There is no one size fits all. We can add an option to control the format later, but for now, Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst case is an admin has to invoke `openssl pkcs7' and concat the certs themselves. > > 4) Over the wire, the certs should be DER-formatted, as that's the most > common wire format in other API commands. > OK. > > 5) What is the benefit in having the CA cert and the rest of the chain > separate? For end-entity certs it makes sense to separate the cert from the > CA chain, but for CA certs, you usually want the full chain, no? > If you want to anchor trust directly at a subca (e.g. restrict VPN login to certs issued by VPN sub-CA) then you often just want the cert. The chain option does subsume it, at cost of more work for administrators with this use case. I think it makes sense to keep both options. Will cut a new patch tomorrow. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file
Please review the attached patch with adds --certificate-out and
--certificate-chain-out options to `ca-show' command.
Note that --certificate-chain-out currently writes a bogus file due
to a bug in Dogtag that will be fixed in this week's build.
https://fedorahosted.org/freeipa/ticket/6178
Thanks,
Fraser
From 6d3a153a954ab09022af6073ae9ea68668716618 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 8 Aug 2016 14:27:20 +1000
Subject: [PATCH] Add options to write lightweight CA cert or chain to file
Administrators need a way to retrieve the certificate or certificate
chain of an IPA-managed lightweight CA. Add --certificate-out and
--certificate-chain-out options to the `ca-show` command.
Fixes: https://fedorahosted.org/freeipa/ticket/6178
---
API.txt | 4 +++-
VERSION | 4 ++--
ipaclient/plugins/ca.py | 40
ipaserver/plugins/ca.py | 23 +--
ipaserver/plugins/dogtag.py | 12
5 files changed, 78 insertions(+), 5 deletions(-)
create mode 100644 ipaclient/plugins/ca.py
diff --git a/API.txt b/API.txt
index
535d8ec9a4990395207e2455a09a8c1bdef5529a..6ed8c5348876aa6ce1ab5d11e14dbcb1e7cee768
100644
--- a/API.txt
+++ b/API.txt
@@ -505,9 +505,11 @@ output: Entry('result')
output: Output('summary', type=[, ])
output: PrimaryKey('value')
command: ca_show/1
-args: 1,4,3
+args: 1,6,3
arg: Str('cn', cli_name='name')
option: Flag('all', autofill=True, cli_name='all', default=False)
+option: Str('certificate_chain_out?')
+option: Str('certificate_out?')
option: Flag('raw', autofill=True, cli_name='raw', default=False)
option: Flag('rights', autofill=True, default=False)
option: Str('version?')
diff --git a/VERSION b/VERSION
index
ca489965050f32d2d8987dfd251ec2b2a0ba1768..3cdb27b806013be2cb0b8b2132c99302865e6358
100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=211
-# Last change: mbabinsk: allow 'value' output param in commands without
primary key
+IPA_API_VERSION_MINOR=212
+# Last change: ftweedal: ca: add options to write cert or cert chain to file
diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py
new file mode 100644
index
..1f4a7c6074b5eb139e01ba2963bf46399ce6d645
--- /dev/null
+++ b/ipaclient/plugins/ca.py
@@ -0,0 +1,40 @@
+#
+# Copyright (C) 2016 FreeIPA Contributors see COPYING for license
+#
+
+from ipaclient.frontend import MethodOverride
+from ipalib import util
+from ipalib.plugable import Registry
+from ipalib.text import _
+
+register = Registry()
+
+
+@register(override=True, no_fail=True)
+class ca_show(MethodOverride):
+def forward(self, *keys, **options):
+if 'certificate_out' in options:
+util.check_writable_file(options['certificate_out'])
+if 'certificate_chain_out' in options:
+util.check_writable_file(options['certificate_chain_out'])
+
+result = super(ca_show, self).forward(*keys, **options)
+summaries = []
+if 'certificate_out' in options and 'certificate' in result['result']:
+with open(options['certificate_out'], 'wb') as f:
+f.write(result['result'].pop('certificate'))
+summaries.append (
+_("Certificate written to file '%(file)s'")
+% dict(file=options['certificate_out'])
+)
+if 'certificate_chain_out' in options and 'chain' in result['result']:
+with open(options['certificate_chain_out'], 'wb') as f:
+f.write(result['result'].pop('chain'))
+summaries.append (
+_("Certificate chain written to file '%(file)s'")
+% dict(file=options['certificate_chain_out'])
+)
+if len(summaries) > 0:
+result['summary'] = '\n'.join(summaries)
+
+return result
diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py
index
966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..70aaca19dbece452c8e679a58ce3754ea75666c5
100644
--- a/ipaserver/plugins/ca.py
+++ b/ipaserver/plugins/ca.py
@@ -140,9 +140,28 @@ class ca_find(LDAPSearch):
class ca_show(LDAPRetrieve):
__doc__ = _("Display the properties of a CA.")
-def execute(self, *args, **kwargs):
+takes_options = LDAPRetrieve.takes_options + (
+Str('certificate_out?',
+doc=_('Write certificate to file'),
+),
+Str('certificate_chain_out?',
+doc=_('Write PKCS #7 certificate chain to file'),
+),
+)
+
+def execute(self, *keys, **options):
ca_enabled_check()
-return super(ca_show, self).execute(*args, **kwargs)
+result = super(ca_show, self).exe
Re: [Freeipa-devel] Broken IPA installations on F24
On Wed, Aug 03, 2016 at 02:17:30PM +0200, Martin Basti wrote: > Hello all, > > > update resteasy-*-3.0.17 from updates-testing prevents IPA (PKI CA) to be > installed on f24, > > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA > instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpEQulGP' returned > non-zero exit status 1 > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation > logs and the following files/directories for more information: > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL > /var/log/pki/pki-tomcat > [error] RuntimeError: CA configuration failed. > ipa.ipapython.install.cli.install_tool(Server): ERRORCA configuration > failed. > ipa.ipapython.install.cli.install_tool(Server): ERRORThe > ipa-server-install command failed. See /var/log/ipaserver-install.log for > more information > > Workaround: > > # dnf downgrade resteasy-atom-provider resteasy-client resteasy-core > resteasy-jackson-provider resteasy-jaxb-provider --allowerasing > > > Please provide negative karma, we must prevent this to get into updates, it > will break IPA 4.3 on F24: > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-d80872c309 > > > Regards > > Martin^2 > I think this is issue https://fedorahosted.org/pki/ticket/2403 which has been fixed by Endi in pki master. We plan to release v10.3.5 next week. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation
On Fri, Jul 29, 2016 at 11:13:16AM -0400, Ben Lipton wrote: > > On 07/29/2016 09:39 AM, Petr Spacek wrote: > > On 27.7.2016 19:06, Ben Lipton wrote: > > > Hi all, > > > > > > I think the automatic CSR generation feature > > > (https://fedorahosted.org/freeipa/ticket/4899, > > > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) > > > is > > > stable enough to review now. The following are summaries of the attached > > > patches: > > > 0004: LDAP schema changes for the new feature > > > 0005: Basic API for new objects and CSR generation > > > 0006: Update install automation to create some default mapping rules > > > 0007: Implement the lookups and text processing that generates the CSR > > > config > > > 0008 and 0009: Implement some actual transformation rules so that the > > > feature > > > is usable > > > 0010: Add a new cert profile for user certs, with mappings > > > 0011: Implement import/export of cert profiles with mappings > > > 0012: Tests for profile import/export > > > > > > Generally speaking, later patches depend on earlier ones, but I don't > > > anticipate any problems from committing earlier patches without later > > > ones. > > > > > > If you prefer, you can also comment on the pull request version: > > > https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on > > > this > > > branch. > > > > > > Allocation of OIDs for schema change also needs review: > > > https://code.engineering.redhat.com/gerrit/#/c/80061/ > > > > > > Known issues: > > > - When the requested principal does not have some of the requested data, > > > produces funny-looking configs with extra commas, empty sections, etc. > > > They > > > are still accepted by my copies of openssl and certutil, but they look > > > ugly. > > > - The new objects don't have any ACIs, so for the moment only admin can > > > run > > > the new commands. > > > - Does not yet have support for prompting user for field values, so > > > currently > > > all data must come from the database. > > > - All processing happens on the server side. As discussed in a previous > > > thread, it would be desirable to break this out into a library so it > > > could be > > > used client-side. > > > > > > Very excited to hear your thoughts! > > Hi Ben, > > > > I wanted to give it a try from user's point of view first, before diving > > into > > implementation details. Here are some observations: > > Thanks for giving it a try! This is great feedback. > > > > 0. Design pages are using term "helper" and it is used even as option in the > > example with smartcards. Please fix either design page or the code so they > > are > > consistent. > Good point. In a previous discussion, Alexander remarked that --helper > sounded too low-level, but I find that --use sounds very generic and > --format doesn't make a lot of sense for ipa cert-request, which never > actually gives you the config that's generated. So if they're all going to > be the same word, which is probably a good idea, I might be leaning towards > --helper, but I'm interested to hear opinions on this. > > > > 1. The "ipa cert-request" command is missing options --autofill and --use > > (aka > > helper aka format :-) which are mentioned in the design pages. > Yeah, I haven't managed to implement much of the UI niceness suggested by > the design page. I probably should have mentioned that in the email - all > that I expect to be working at this point is 'ipa cert-get-requestdata' and > CRUD for the mapping rules/profiles themselves. > > > > 2. "ipa cert_get_requestdata" command passes even without --profile-id and > > generates empty config. I think that this is not expected :-) > > More expected than you might think :) I'm guessing what's happening is that > you're passing a user principal and it's defaulting to the caIPAserviceCert > profile, then failing to fill out any of the fields because the data it > needs is not there. I agree this isn't great. I was planning to address this > by having it throw an error if it can't generate at least the subject of the > request, and maybe suggest using a different profile. > > I chose to have it default to caIPAserviceCert because that's what ipa > cert-request does, but maybe that's not as predictable as I thought. > In general use I think that 'caIPAserviceCert' is unlikely to be used a majory of the time, and it is a new command so there are no compatibility issues; therefore why not make the profile option mandatory? > > > > 3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout > > including label "Configuration file contents:". This is hard to use because > > simple redirection like "ipa cert_get_requestdata --format=openssl > config" > > will not give you valid OpenSSL config file - it needs hand-editing. > > > > It would be good to add --out parameter you envisioned in the design page. > > Please ask jcholast for proper name and semantics :-) With --out option the > > command
Re: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation
On Thu, Jul 28, 2016 at 09:56:30AM +0200, Martin Babinsky wrote:
> On 07/28/2016 03:31 AM, Fraser Tweedale wrote:
> > The attached patch fixes a kerberos.Principal-related regression.
> >
> > Thanks,
> > Fraser
> >
> Hi Fraser,
>
> The ticket you linked in the commit message points to a closed milestone.
> You have to open a new ticket which needs to be triaged. Sorry, those are
> the processes.
>
Filed ticket: https://fedorahosted.org/freeipa/ticket/6146
Updated patch attached (rebase and update commit message only).
Thanks,
Fraser
From ef74c727e31a08af679eeeca027dd6a6bf526f0e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 28 Jul 2016 10:55:45 +1000
Subject: [PATCH] caacl: fix regression in rule instantiation
The Principal refactor causes service collections
('memberservice_service' attribute) to return Principal objects
where previously it returned strings, but the HBAC machinery used
for CA ACL enforcement only handles strings. Update the code to
stringify service Principal objects when adding them to HBAC rules.
Fixes: https://fedorahosted.org/freeipa/ticket/6146
---
ipaserver/plugins/caacl.py | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py
index
d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a..a7817c4cf64f070c74557f52e9f26c9013a4963c
100644
--- a/ipaserver/plugins/caacl.py
+++ b/ipaserver/plugins/caacl.py
@@ -132,16 +132,21 @@ def _acl_make_rule(principal_type, obj):
rule.services.names = obj.get(attr, [])
# add principals and principal's groups
-m = {'user': 'group', 'host': 'hostgroup', 'service': None}
category_attr = '{}category'.format(principal_type)
if category_attr in obj and obj[category_attr][0].lower() == 'all':
rule.users.category = {pyhbac.HBAC_CATEGORY_ALL}
else:
-principal_attr = 'member{}_{}'.format(principal_type, principal_type)
-rule.users.names = obj.get(principal_attr, [])
-if m[principal_type] is not None:
-group_attr = 'member{}_{}'.format(principal_type,
m[principal_type])
-rule.users.groups = obj.get(group_attr, [])
+if principal_type == 'user':
+rule.users.names = obj.get('memberuser_user', [])
+rule.users.groups = obj.get('memberuser_group', [])
+elif principal_type == 'host':
+rule.users.names = obj.get('memberhost_host', [])
+rule.users.groups = obj.get('memberhost_hostgroup', [])
+elif principal_type == 'service':
+rule.users.names = [
+unicode(principal)
+for principal in obj.get('memberservice_service', [])
+]
return rule
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation
The attached patch fixes a kerberos.Principal-related regression.
Thanks,
Fraser
From c3d4bee34f4a1aa6afafee07851e8b5557860331 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 28 Jul 2016 10:55:45 +1000
Subject: [PATCH] caacl: fix regression in rule instantiation
The Principal refactor causes service collections
('memberservice_service' attribute) to return Principal objects
where previously it returned strings, but the HBAC machinery used
for CA ACL enforcement only handles strings. Update the code to
stringify service Principal objects when adding them to HBAC rules.
Part of: https://fedorahosted.org/freeipa/ticket/3864
---
ipaserver/plugins/caacl.py | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py
index
d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a..a7817c4cf64f070c74557f52e9f26c9013a4963c
100644
--- a/ipaserver/plugins/caacl.py
+++ b/ipaserver/plugins/caacl.py
@@ -132,16 +132,21 @@ def _acl_make_rule(principal_type, obj):
rule.services.names = obj.get(attr, [])
# add principals and principal's groups
-m = {'user': 'group', 'host': 'hostgroup', 'service': None}
category_attr = '{}category'.format(principal_type)
if category_attr in obj and obj[category_attr][0].lower() == 'all':
rule.users.category = {pyhbac.HBAC_CATEGORY_ALL}
else:
-principal_attr = 'member{}_{}'.format(principal_type, principal_type)
-rule.users.names = obj.get(principal_attr, [])
-if m[principal_type] is not None:
-group_attr = 'member{}_{}'.format(principal_type,
m[principal_type])
-rule.users.groups = obj.get(group_attr, [])
+if principal_type == 'user':
+rule.users.names = obj.get('memberuser_user', [])
+rule.users.groups = obj.get('memberuser_group', [])
+elif principal_type == 'host':
+rule.users.names = obj.get('memberhost_host', [])
+rule.users.groups = obj.get('memberhost_hostgroup', [])
+elif principal_type == 'service':
+rule.users.names = [
+unicode(principal)
+for principal in obj.get('memberservice_service', [])
+]
return rule
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension
While I was poking around SAN-processing code, I decided to
implement a small enhancement: allowing the subject principal's DN
to appear in SAN.
https://fedorahosted.org/freeipa/ticket/6112
Patch depends on my other patches 0090, 0092, 0093, 0094.
Thanks,
Fraser
From 6a2ab7165c0ae600402c1c2794f2b10c9e38da05 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 22 Jul 2016 13:07:09 +1000
Subject: [PATCH] cert-request: allow directoryName in SAN extension
Allow directoryName in SAN extension if the value matches the
subject principal's DN in the IPA directory.
Fixes: https://fedorahosted.org/freeipa/ticket/6112
---
ipaserver/plugins/cert.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py
index
606d6cdbc28d30892ab60ad4aeb41ecbbd646589..605fd321f00304f69347aae633f935dde8e59bdc
100644
--- a/ipaserver/plugins/cert.py
+++ b/ipaserver/plugins/cert.py
@@ -667,6 +667,12 @@ class cert_request(Create, BaseCertMethod, VirtualCommand):
error=_("subject alt name type %s is forbidden "
"for non-user principals") % desc
)
+elif name_type == nss.certDirectoryName:
+if DN(name) != principal_obj['dn']:
+raise errors.ValidationError(
+name='csr',
+error=_("Directory Name does not match principal's DN")
+)
else:
raise errors.ACIError(
info=_("Subject alt name type %s is forbidden") % desc)
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names
On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote:
> Hi,
>
> On 14.7.2016 13:44, Fraser Tweedale wrote:
> > Hi all,
> >
> > The attached patch includes SANs in cert-show output. If you have
> > certs with esoteric altnames (especially any that are more than just
> > ASN.1 string types), please test with those certs.
> >
> > https://fedorahosted.org/freeipa/ticket/6022
>
> I think it would be better to have a separate attribute for each supported
> SAN type rather than cramming everything into subject_alt_name. That way if
> you care only about a single specific type you won't have to go through all
> the values and parse them. Also it would allow you to use param types
> appropriate to the SAN types (DNSNameParam for DNS names, Principal for
> principal names, etc.)
>
> Nitpick: please don't mix moving existing stuff and adding new stuff in a
> single patch.
>
Updated patches attached.
Patches 0092..0094 are refactors and bugfixes.
Patch 0090-2 is the main feature (depends on 0092..0094).
Thanks,
Fraser
From 0f85eba4efdd9281725c54268e8d213c412edebf Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 21 Jul 2016 16:27:49 +1000
Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509
GeneralName parsing code is primarily relevant to X.509. An
upcoming change will add SAN parsing to the cert-show command, so
first move the GeneralName parsing code from ipalib.pkcs10 to
ipalib.x509.
Part of: https://fedorahosted.org/freeipa/ticket/6022
---
ipalib/pkcs10.py | 93 ++---
ipalib/x509.py| 114 +-
ipaserver/plugins/cert.py | 8 ++--
3 files changed, 120 insertions(+), 95 deletions(-)
diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py
index
e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c
100644
--- a/ipalib/pkcs10.py
+++ b/ipalib/pkcs10.py
@@ -22,9 +22,10 @@ from __future__ import print_function
import sys
import base64
import nss.nss as nss
-from pyasn1.type import univ, char, namedtype, tag
+from pyasn1.type import univ, namedtype, tag
from pyasn1.codec.der import decoder
import six
+from ipalib import x509
if six.PY3:
unicode = str
@@ -32,11 +33,6 @@ if six.PY3:
PEM = 0
DER = 1
-SAN_DNSNAME = 'DNS name'
-SAN_RFC822NAME = 'RFC822 Name'
-SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)'
-SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)'
-
def get_subject(csr, datatype=PEM):
"""
Given a CSR return the subject value.
@@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM):
return tuple(get_prefixed_oid_str(ext)[4:]
for ext in request.extensions)
-class _PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('name-type', univ.Integer().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('name-string',
univ.SequenceOf(char.GeneralString()).subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-class _KRB5PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('realm', char.GeneralString().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('principalName', _PrincipalName().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-def _decode_krb5principalname(data):
-principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0]
-realm = (str(principal['realm']).replace('\\', '')
-.replace('@', '\\@'))
-name = principal['principalName']['name-string']
-name = '/'.join(str(n).replace('\\', '')
- .replace('/', '\\/')
- .replace('@', '\\@') for n in name)
-name = '%s@%s' % (name, realm)
-return name
-
-class _AnotherName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('type-id', univ.ObjectIdentifier()),
-namedtype.NamedType('value', univ.Any().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-)
-
-class _GeneralName(univ.Choice):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('otherName', _AnotherName().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('rfc822Name', char.IA5String().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-namedtype.NamedType('dNSName', char.IA5String().subtype(
-i
Re: [Freeipa-devel] [PATCH] 0046 Create server certs with DNS altname
On Tue, Jul 19, 2016 at 02:21:05PM +0200, Martin Basti wrote: > > > On 01.07.2016 13:26, Petr Spacek wrote: > > On 20.1.2016 05:04, Fraser Tweedale wrote: > > > On Tue, Dec 08, 2015 at 07:06:39PM +1000, Fraser Tweedale wrote: > > > > On Mon, Dec 07, 2015 at 05:50:05PM -0500, Rob Crittenden wrote: > > > > > Fraser Tweedale wrote: > > > > > > On Mon, Dec 07, 2015 at 01:53:15PM +0100, Martin Kosek wrote: > > > > > > > On 12/07/2015 06:26 AM, Fraser Tweedale wrote: > > > > > > > > The attached patch fixes > > > > > > > > https://fedorahosted.org/freeipa/ticket/4970. > > > > > > > > > > > > > > > > Note that the problem is addressed by adding the appropriate > > > > > > > > request > > > > > > > > extension to the CSR; the fix does not involve changing the > > > > > > > > default > > > > > > > > profile behaviour, which is complicated (see ticket for > > > > > > > > details). > > > > > > > Thanks for the patch! This is something we should really fix, I > > > > > > > already get > > > > > > > warnings in my Python scripts when I hit sites protected by such > > > > > > > HTTPS cert: > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:264: > > > > > > > SubjectAltNameWarning: Certificate for > > > > > > > projects.engineering.redhat.com has no > > > > > > > `subjectAltName`, falling back to check for a `commonName` for > > > > > > > now. This > > > > > > > feature is being removed by major browsers and deprecated by RFC > > > > > > > 2818. (See > > > > > > > https://github.com/shazow/urllib3/issues/497 for details.) > > > > > > > > > > > > > > Should we split ticket 4970, for the FreeIPA server part and then > > > > > > > for cert > > > > > > > profile part? As it looks like the FreeIPA server will be fixed > > > > > > > even in FreeIPA > > > > > > > 4.3.x and the other part later. > > > > > > > > > > > > > > How difficult do you see the general FreeIPA Certificate Profile > > > > > > > part of this > > > > > > > request? Is it a too big task to handle in 4.4 time frame? > > > > > > > > > > > > > I will split the ticket and would suggest 4.4 Backlog - it might be > > > > > > doable but is a lower priority than e.g. Sub-CAs. > > > > > If you are going to defer the profile part then you should probably > > > > > update the client to also include a SAN if --request-cert is provided. > > > > > > > > > > rob > > > > > > > > > Yes, good idea. Updated patch attached. > > > > > > > > Cheers, > > > > Fraser > > > Bump, with rebased patch. > > Hi, > > > > this seems to work for Apache on IPA server & client cert. ACK. > Pushed to master: b12db924143cd6828c596c0b8a261325f3f589f3 > > > > > Interestingly enough I found out that Dogtag cert used on port 8443 does not > > have any SAN. > > > > Is it in scope of this ticket? > I will leave the ticket open until this is answered. > It's in scope. Also in scope is to make default profile automatically add SAN dNSName if none is supplied. Thanks, Fraser > Martin^2 > > > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name
On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > Hi, > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > The attached patch is a work in progress for > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > It has been tested for server install, replica install (with and > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > Migration from earlier versions and server/replica/CA install on a > > > CA-less deployment are not yet tested; these will be tested over > > > coming days and patch will be tweaked as necessary. > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > me know your questions and comments. > > > > > > Thanks, > > > Fraser > > > > > It does help to attach the patch, of course ^_^ > > IMO explicit is better than implicit, so instead of introducing additional > magic around --subject, I would rather add a new separate option for > specifying the CA subject name (I think --ca-subject, for consistency with > --ca-signing-algorithm). > The current situation - the --subject argument which specifies the not the subject but the subject base, is confusing enough (to say nothing of the limitations that give rise to the RFE). Retaining --subject for specifying the subject base and adding --ca-subject for specifying the *actual* subject DN gets us over the line in terms of the RFE, but does not make the installer less confusing. This is why I made --subject accept the full subject DN, with provisions to retain existing behaviour. IMO if we want to have separate arguments for subject DN and subject base (I am not against it), let's bite the bullet and name arguments accordingly. --subject should be used to specify full Subject DN, --subject-base (or similar) for specifying subject base. (I intentionally defer discussion of specific behaviour if one, none or both are specified; let's resolve the question or renaming / changing meaning of arguments first). > By specifying the option you would override the default "CN=Certificate > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > additional validation would be done to make sure the subject name meets > Dogtag's expectations. Actually, it might make sense to always do the > additional validation, to be able to print a warning that if a > Dogtag-incompatible subject name is used, it won't be possible to change the > CA cert chaining from externally signed to self-signed later. > > Honza > > -- > Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] cert-show: show subject alternative names
On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: > Hi, > > On 14.7.2016 13:44, Fraser Tweedale wrote: > > Hi all, > > > > The attached patch includes SANs in cert-show output. If you have > > certs with esoteric altnames (especially any that are more than just > > ASN.1 string types), please test with those certs. > > > > https://fedorahosted.org/freeipa/ticket/6022 > > I think it would be better to have a separate attribute for each supported > SAN type rather than cramming everything into subject_alt_name. That way if > you care only about a single specific type you won't have to go through all > the values and parse them. Also it would allow you to use param types > appropriate to the SAN types (DNSNameParam for DNS names, Principal for > principal names, etc.) > You are right; that would be much better. > Nitpick: please don't mix moving existing stuff and adding new stuff in a > single patch. > Will cut new patches to address both of these points. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL
On Tue, Jul 19, 2016 at 08:26:22AM +0200, Jan Cholasta wrote: > Hi, > > On 4.7.2016 09:06, Fraser Tweedale wrote: > > On Tue, Jun 28, 2016 at 01:47:23PM -, freeipa wrote: > > > #6002: Default CA can be used without an ACL > > > > > > Comment (by ftweedal): > > > > > > This is expected behaviour; if a CA ACL does not reference any CAs, > > > and does not have cacat=all, then it is assumed to refer to the > > > default CA. This is for backwards compatibility with existing > > > CA ACLs, which do not reference any CAs but did (and still do) > > > allow access to IPA CA. > > > > > > Leaving open for discussion about whether to break compatibility > > > for a more consistent behaviour. > > > > > Didn't get any feedback in the ticket yet so raising on list for > > visibility. If people agree with current behaviour I can add a > > clarification to caacl plugin help text and close out this ticket. > > (Sorry for the late reply, I was on vacation the last 2 weeks.) > > I would very much prefer if this was consistent with (literally) every other > member list+category attribute, that is, no member and no category means the > rule never matches. > > While documenting this as an exception to the above rule is the easy way > out, IMHO adhering to the rule is even better - anyone who touched HBAC or > sudo in IPA would immediately know their way around CA ACLs without having > to read the documentation at all, which is a win, because people don't > generally read documentation until something goes wrong. The current > behavior might surprise them, even if documented properly (it sure surprised > me at first :-). > > BTW I think this can be done without breaking compatibility, e.g. by using a > new objectclass to distinguish between "old" (CA is always implicitly the > top-level CA) and "new" (CAs are specified using the member and category > attributes) CA ACLs. > > Honza > Is there precedent of "varying behaviour based on objectclass" in IPA? Would it go along the lines of... 1. subtype 'ipaCaAcl' object class (let us call it 'ipaCaAclWithCa' for sake of discussion). (Note that moving the 'ipaCa' attribute to be part of 'ipaCaAclWithCa' would not be backwards compatible with v4.4 as currently released, so it would remain in 'ipaCaAcl' objectclass.) 2. Upgrade script to take 'ipaCaAcl' objects that are NOT 'ipaCaAclWithCa', and make them so, while adding the IPA CA. Is this what you have in mind? If so, I don't think there is actually a need to vary the behaviour based on object class, other than during upgrade. The reason I was not doing upgrades in the first place was because I could not in distinguish between "old" CA ACLs, and "new" CA ACLs that don't have any CAs defined. However, adding a new objectclass resolves this ambiguity. Lmk what you think; I could be way off track :) Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation
On Mon, Jul 18, 2016 at 09:55:21AM +0200, Martin Basti wrote:
>
>
> On 13.07.2016 18:34, Petr Vobornik wrote:
> > On 07/12/2016 08:45 AM, Alexander Bokovoy wrote:
> > > On Tue, 12 Jul 2016, Fraser Tweedale wrote:
> > > > Attached patch is a doc change, addressing
> > > > https://fedorahosted.org/freeipa/ticket/6002.
> > > >
> > > > Thanks,
> > > > Fraser
> > > > From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001
> > > > From: Fraser Tweedale <ftwee...@redhat.com>
> > > > Date: Tue, 12 Jul 2016 15:11:11 +1000
> > > > Subject: [PATCH] caacl: expand plugin documentation
> > > >
> > > > Expand the 'caacl' plugin documentation to explain some common
> > > > confusions including the fact that CA ACLs apply to the target
> > > > subject principal (not necessarily the principal requesting the
> > > > cert), and the fact that CA-less CA ACL implies the 'ipa' CA.
> > > >
> > > > Fixes: https://fedorahosted.org/freeipa/ticket/6002
> > > > ---
> > > > ipaserver/plugins/caacl.py | 34 --
> > > > 1 file changed, 28 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py
> > > > index
> > > > 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a
> > > > 100644
> > > > --- a/ipaserver/plugins/caacl.py
> > > > +++ b/ipaserver/plugins/caacl.py
> > > > @@ -23,14 +23,36 @@ if six.PY3:
> > > > __doc__ = _("""
> > > > Manage CA ACL rules.
> > > >
> > > > -This plugin is used to define rules governing which principals are
> > > > -permitted to have certificates issued using a given certificate
> > > > -profile.
> > > > +This plugin is used to define rules governing which CAs and profiles
> > > > +may be used to issue certificates to particular principals or groups
> > > > +of principals.
> > > >
> > > > -PROFILE ID SYNTAX:
> > > > +SUBJECT PRINCIPAL SCOPE:
> > > >
> > > > -A Profile ID is a string without spaces or punctuation starting with
> > > > a letter
> > > > -and followed by a sequence of letters, digits or underscore ("_").
> > > > +For a certificate request to be allowed, the principal(s) that are
> > > > +the subject of a certificate request (not necessarily the principal
> > > > +actually requesting the certificate) must be included in the scope
> > > > +of a CA ACL that also includes the target CA and profile.
> > > > +
> > > > +Users can be included by name, group or the "all users" category.
> > > > +Hosts can be included by name, hostgroup or the "all hosts"
> > > > +category. Services can be included by service name or the "all
> > > > +services" category. CA ACLs may be associated with a single type of
> > > > +principal, or multiple types.
> > > > +
> > > > +CERTIFICATE AUTHORITY SCOPE:
> > > > +
> > > > +A CA ACL can be associated with one or more CAs by name, or by the
> > > > +"all CAs" category. For compatibility reasons, a CA ACL with no CA
> > > > +association implies an association with the 'ipa' CA (and only this
> > > > +CA).
> > > > +
> > > > +PROFILE SCOPE:
> > > > +
> > > > +A CA ACL can be associated with one or more profiles by Profile ID.
> > > > +The Profile ID is a string without spaces or punctuation starting
> > > > +with a letter and followed by a sequence of letters, digits or
> > > > +underscore ("_").
> > > >
> > > > EXAMPLES:
> > > >
> > > ACK. Reads well.
> > >
> > Pushed to master: 8cd87d12d53a98a8e386c06a7c5fddb1d38d990d
> >
> Please note for future, that long string should be splitted, to make life of
> translators easier
>
> http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings
>
> Martin^2
>
I see; thanks for pointing this out Martin.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name
On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote:
> The attached patch is a work in progress for
> https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866).
>
> I am sharing now to make the approach clear and solicit feedback.
>
> It has been tested for server install, replica install (with and
> without CA) and CA-replica install (all hosts running master+patch).
>
> Migration from earlier versions and server/replica/CA install on a
> CA-less deployment are not yet tested; these will be tested over
> coming days and patch will be tweaked as necessary.
>
> Commit message has a fair bit to say so I won't repeat here but let
> me know your questions and comments.
>
> Thanks,
> Fraser
>
It does help to attach the patch, of course ^_^
From 74102e13b041cd05396a579f12f26a9f80394ad1 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 11 Jul 2016 12:57:11 +1000
Subject: [PATCH] Allow full customisability of IPA CA subject DN
Currently only the "subject base" of the IPA CA subject DN can be
customised via the installer's --subject option. The RDN
"CN=Certificate Authority" is appended to form the subject DN, and
this composition is widely assumed, hardcoded in many places.
Some administrators need more control over the CA subject DN,
especially to satisfy expectations of external CAs when the IPA CA
is to be externally signed.
This patch adds full customisability of the CA subject DN. The
--subject argument can now be the full DN, and the subject base is
derived from it. The full rules are as follows:
- If --subject is not given, default to
"CN=Certificate Authority, O=$REALM" (existing behaviour)
- If --external-ca is used, subject is used as-is.
- If and only if --external-ca is not used, to meet Dogtag's
expectations, the "most specific" CN AVA encountered shall be the
most specific RDN (it is moved if necessary); if the subject DN
does not contain a CN AVA, then "CN=Certificate Authority" is
appended.
- The subject base is derived from the subject (after processing per
preceding points) by extracting OU, O, L, ST, C and DC AVAs,
preserving relative order. If the resulting DN is empty, it
defaults to "O=$REALM".
Fixes: https://fedorahosted.org/freeipa/ticket/2614
---
install/share/certmap.conf.template| 2 +-
install/tools/ipa-ca-install | 14 +---
install/tools/man/ipa-server-install.1 | 2 +-
ipapython/ipautil.py | 20 +
ipaserver/install/ca.py| 20 +
ipaserver/install/cainstance.py| 35 ++
ipaserver/install/certs.py | 9
ipaserver/install/dsinstance.py| 29 +++--
ipaserver/install/installutils.py | 35 +++---
ipaserver/install/ipa_cacert_manage.py | 9 ++--
ipaserver/install/krainstance.py | 9 +---
ipaserver/install/server/common.py | 4 ++--
ipaserver/install/server/install.py| 17 ++-
ipaserver/install/server/replicainstall.py | 27 ---
14 files changed, 159 insertions(+), 73 deletions(-)
diff --git a/install/share/certmap.conf.template
b/install/share/certmap.conf.template
index
e76bf3c653a4f1d130ce8c264a28cac5dc63925c..d59b095faff804eae4cbd2ef984aa8ca3be52946
100644
--- a/install/share/certmap.conf.template
+++ b/install/share/certmap.conf.template
@@ -41,6 +41,6 @@ certmap default default
#default:InitFn
default:DNComps
default:FilterComps uid
-certmap ipaca CN=Certificate Authority,$SUBJECT_BASE
+certmap ipaca $ISSUER_DN
ipaca:CmapLdapAttr seeAlso
ipaca:verifycerton
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index
ed685920cbadb9cd3fc80865afb1610ca42f8b13..8a8adb3984386bb88227d769a8c5132bb121b870
100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -32,7 +32,7 @@ from ipaserver.install import bindinstance, dsinstance, ca
from ipaserver.install import cainstance, custodiainstance, service
from ipapython import version
from ipalib import api
-from ipalib.constants import DOMAIN_LEVEL_0
+from ipalib.constants import DOMAIN_LEVEL_0, IPA_CA_CN
from ipapython.dn import DN
from ipapython.config import IPAOptionParser
from ipapython.ipa_log_manager import root_logger, standard_logging_setup
@@ -160,9 +160,7 @@ def install_replica(safe_options, options, filename):
conn.connect(bind_dn=DN(('cn', 'Directory Manager')),
bind_pw=dirman_password)
-if config.subject_base is None:
-attrs = conn.get_ipa_config()
-config.subject_base = attrs.get('ipacertificatesubjectbase')[0]
+subject = api.Command.ca_show(IPA_CA_CN)['result'][
[Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name
The attached patch is a work in progress for https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). I am sharing now to make the approach clear and solicit feedback. It has been tested for server install, replica install (with and without CA) and CA-replica install (all hosts running master+patch). Migration from earlier versions and server/replica/CA install on a CA-less deployment are not yet tested; these will be tested over coming days and patch will be tweaked as necessary. Commit message has a fair bit to say so I won't repeat here but let me know your questions and comments. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] cert-show: show subject alternative names
Hi all,
The attached patch includes SANs in cert-show output. If you have
certs with esoteric altnames (especially any that are more than just
ASN.1 string types), please test with those certs.
https://fedorahosted.org/freeipa/ticket/6022
Thanks,
Fraser
From f56d698009f32a1b8760048848117148164fad33 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 14 Jul 2016 21:36:33 +1000
Subject: [PATCH] cert-show: show subject alternative names
Update the cert-show command to return subject alternative name
values.
Also move GeneralName parsing code from ipalib.pkcs10 to
ipalib.x509.
Part of: https://fedorahosted.org/freeipa/ticket/6022
---
ipalib/pkcs10.py | 93 ++---
ipalib/x509.py| 114 +-
ipaserver/plugins/cert.py | 28 ++--
3 files changed, 140 insertions(+), 95 deletions(-)
diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py
index
e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c
100644
--- a/ipalib/pkcs10.py
+++ b/ipalib/pkcs10.py
@@ -22,9 +22,10 @@ from __future__ import print_function
import sys
import base64
import nss.nss as nss
-from pyasn1.type import univ, char, namedtype, tag
+from pyasn1.type import univ, namedtype, tag
from pyasn1.codec.der import decoder
import six
+from ipalib import x509
if six.PY3:
unicode = str
@@ -32,11 +33,6 @@ if six.PY3:
PEM = 0
DER = 1
-SAN_DNSNAME = 'DNS name'
-SAN_RFC822NAME = 'RFC822 Name'
-SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)'
-SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)'
-
def get_subject(csr, datatype=PEM):
"""
Given a CSR return the subject value.
@@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM):
return tuple(get_prefixed_oid_str(ext)[4:]
for ext in request.extensions)
-class _PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('name-type', univ.Integer().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('name-string',
univ.SequenceOf(char.GeneralString()).subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-class _KRB5PrincipalName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('realm', char.GeneralString().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('principalName', _PrincipalName().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-)
-
-def _decode_krb5principalname(data):
-principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0]
-realm = (str(principal['realm']).replace('\\', '')
-.replace('@', '\\@'))
-name = principal['principalName']['name-string']
-name = '/'.join(str(n).replace('\\', '')
- .replace('/', '\\/')
- .replace('@', '\\@') for n in name)
-name = '%s@%s' % (name, realm)
-return name
-
-class _AnotherName(univ.Sequence):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('type-id', univ.ObjectIdentifier()),
-namedtype.NamedType('value', univ.Any().subtype(
-explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-)
-
-class _GeneralName(univ.Choice):
-componentType = namedtype.NamedTypes(
-namedtype.NamedType('otherName', _AnotherName().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0))
-),
-namedtype.NamedType('rfc822Name', char.IA5String().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1))
-),
-namedtype.NamedType('dNSName', char.IA5String().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2))
-),
-namedtype.NamedType('x400Address', univ.Sequence().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3))
-),
-namedtype.NamedType('directoryName', univ.Choice().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4))
-),
-namedtype.NamedType('ediPartyName', univ.Sequence().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5))
-),
-namedtype.NamedType('uniformResourceIdentifier',
char.IA5String().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6))
-),
-namedtype.NamedType('iPAddress', univ.OctetString().subtype(
-implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7))
-),
-namedtype.Na
[Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation
Attached patch is a doc change, addressing
https://fedorahosted.org/freeipa/ticket/6002.
Thanks,
Fraser
From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Tue, 12 Jul 2016 15:11:11 +1000
Subject: [PATCH] caacl: expand plugin documentation
Expand the 'caacl' plugin documentation to explain some common
confusions including the fact that CA ACLs apply to the target
subject principal (not necessarily the principal requesting the
cert), and the fact that CA-less CA ACL implies the 'ipa' CA.
Fixes: https://fedorahosted.org/freeipa/ticket/6002
---
ipaserver/plugins/caacl.py | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py
index
9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a
100644
--- a/ipaserver/plugins/caacl.py
+++ b/ipaserver/plugins/caacl.py
@@ -23,14 +23,36 @@ if six.PY3:
__doc__ = _("""
Manage CA ACL rules.
-This plugin is used to define rules governing which principals are
-permitted to have certificates issued using a given certificate
-profile.
+This plugin is used to define rules governing which CAs and profiles
+may be used to issue certificates to particular principals or groups
+of principals.
-PROFILE ID SYNTAX:
+SUBJECT PRINCIPAL SCOPE:
-A Profile ID is a string without spaces or punctuation starting with a letter
-and followed by a sequence of letters, digits or underscore ("_").
+For a certificate request to be allowed, the principal(s) that are
+the subject of a certificate request (not necessarily the principal
+actually requesting the certificate) must be included in the scope
+of a CA ACL that also includes the target CA and profile.
+
+Users can be included by name, group or the "all users" category.
+Hosts can be included by name, hostgroup or the "all hosts"
+category. Services can be included by service name or the "all
+services" category. CA ACLs may be associated with a single type of
+principal, or multiple types.
+
+CERTIFICATE AUTHORITY SCOPE:
+
+A CA ACL can be associated with one or more CAs by name, or by the
+"all CAs" category. For compatibility reasons, a CA ACL with no CA
+association implies an association with the 'ipa' CA (and only this
+CA).
+
+PROFILE SCOPE:
+
+A CA ACL can be associated with one or more profiles by Profile ID.
+The Profile ID is a string without spaces or punctuation starting
+with a letter and followed by a sequence of letters, digits or
+underscore ("_").
EXAMPLES:
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install
On Fri, Jul 08, 2016 at 01:54:33PM +0200, Sebastian Hetze wrote: > On 07/08/2016 12:57 PM, Sebastian Hetze wrote: > > > > > > With your proposal, a subject would look like this: > > Subject: CN=Custom CA Name,E=caad...@example.com,OU=Example IT,O=Example > > Corp,L=City,ST=State,C=US > > I was not proposing that the DN contain all those components; merely that particular components, if present, would be extract to form the subject base. In the case of --external-ca, the argument to --subject would be used as-is in the CSR. > > I will check with my customer if this can possibly be signed by the AD > > PKI, and if that works what the ordering looks like after signing. > As I expected, the AD PKI brings the whole subject line into canonical > order, resulting in that subject: > > Subject: E=caad...@example.com,CN=Custom CA Name,OU=Example IT,O=Example > Corp,L=City,ST=State,C=US > > Since the ipa-server-install requires the subject of the signed cert to > match exactly the subject from the CSR, we need to construct the subject > line exactly as I do in my proposed patch. > > And, as I said, the patch works with freeipa-4.2.0 as shipped with RHEL-7.2 > It may work fine, but I feel it is not the best approach to add new arguments extra arguments. Your preliminary work and knowledge of the case are valuable. I will implement the single --subject argument approach and we can check that it meets the requirements. Thanks, Fraser > > Beste Grüße / Best regards > Sebastian Hetze > -- > Senior Solution Architect > Red Hat GmbH. Niederlassung Berlin > Am Treptower Park 75 12435 Berlin > Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 > Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install
On Fri, Jul 08, 2016 at 01:18:23PM +0200, Petr Spacek wrote: > On 8.7.2016 05:42, Fraser Tweedale wrote: > > > > 2. If argument contains CN but it is not the "most specific" > > RDN, move it to the front (to satisfy requirement of Dogtag > > profile). > > I wonder if we can relax the requirement in Dogtag so no reordering is needed. > After all, DN is just a name, isn't it? Why Dogtag requires particular field > in DN? > Cc pki-devel@. The subject name constraint in the caCAcert profile is: policyset.caCertSet.1.constraint.params.pattern=CN=.* What do you think? Can we relax or remove this constraint - or if not, why is it required? Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3
On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote:
> Hello,
>
> IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for
> Fedora any time soon?
>
> Or should I update my scripts to automatically enable
> COPR @freeipa/freeipa-master
> in my testing VMs?
>
> Thanks.
> Petr^2 Spacek
>
Hi Petr,
The required features were released for Fedora as 10.3.3-3.
Attached patch retracts the min required version accordingly.
Thanks,
Fraser
From f6fd4c9c7838e841e1a3728d7e9afbe5f081927d Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 8 Jul 2016 14:47:06 +1000
Subject: [PATCH] spec: require Dogtag >= 10.3.3-3
Required features that were expected to be released in Dogtag 10.3.4
have instead been released for Fedora in 10.3.3-3. Retract the
minimum required version.
https://fedorahosted.org/freeipa/ticket/5956
---
freeipa.spec.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index
ff27a32eebcc640cdbc8895f47732f06a90c4a1b..135e9c980011c6c2730c6c29a3c22098e48270d5
100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -94,7 +94,7 @@ BuildRequires: libunistring-devel
BuildRequires: python-lesscpy
BuildRequires: python-yubico >= 1.2.3
BuildRequires: openssl-devel
-BuildRequires: pki-base >= 10.3.4
+BuildRequires: pki-base >= 10.3.3-3
BuildRequires: python-pytest-multihost >= 0.5
BuildRequires: python-pytest-sourceorder
BuildRequires: python-kdcproxy >= 0.3
@@ -155,8 +155,8 @@ Requires(post): systemd-units
Requires: selinux-policy >= %{selinux_policy_version}
Requires(post): selinux-policy-base >= %{selinux_policy_version}
Requires: slapi-nis >= 0.56.0
-Requires: pki-ca >= 10.3.4
-Requires: pki-kra >= 10.3.4
+Requires: pki-ca >= 10.3.3-3
+Requires: pki-kra >= 10.3.3-3
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: zip
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [patch 0038-0040] Sub CA test patches
On Thu, Jul 07, 2016 at 03:46:52PM +0200, Milan Kubík wrote:
> On 07/04/2016 08:57 AM, Fraser Tweedale wrote:
> > Hi Milan,
> >
> > Yes, we can :) Two issues, outlined below.
> >
> >
> > 1)
> > Running the tests, I get error in
> > test_create_subca_with_subject_conflict cleanup::
> >
> > ERROR at teardown of
> > TestCAbasicCRUD.test_create_subca_with_subject_conflict _
> >
> > def cleanup():
> > created = self.exists
> > try:
> > del_command()
> >
> >
> > E NotFound: crud-subca-2: Certificate Authority not found
> >
> >
> > I do not know testing framework very well but it looks like
> > track_create() sets 'self.exists = True' before the create command
> > throws the (expected) DuplicateEntry error. (These are called from
> > create() in the tracker 'base' class). Later, cleanup() catches a
> > NotFound but re-throws it because it believes the entry should have
> > existed.
> >
> >
> > 2)
> > the usercert.conf.tmpl does not like a subject base with spaces in
> > it, i.e. if 'openssl req' config template gets formatted like:
> >
> > [ dn ]
> > commonName = "alice"
> > o=IPA.LOCAL 201606201330
> >
> > then 'openssl req' fails with nasty error like:
> >
> > 140644791924600:error:0D06407A:asn1 encoding
> > routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108:
> > 140644791924600:error:0B083077:x509 certificate
> > routines:X509_NAME_ENTRY_create_by_txt:invalid field
> > name:x509name.c:295:name=o
> >
> > and CalledProcessError gets raised and the test fails.
> >
> > Simplest solution is to simply remove the '{ipacertbase}' from the
> > template, because AFAIK it is not needed and parsing and formatting
> > the certbase (which could have multiple AVAs) is more complex than
> > the test calls for, IMO.
> >
> >
> > Thanks,
> > Fraser
> Hi, thanks.
>
> I must have missed the first issue after I removed the expected fail marker.
> I have fixed it now.
>
> As for the usercert template, this code is older than the issues at hand. I
> do not remember why exactly I used that
> option in the openssl config. I have removed that in a new patch.
>
Thanks Milan,
All working for me now. ACK on all four patches.
Cheers,
Fraser
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install
On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote: > > > On 07/07/2016 03:16 PM, Rob Crittenden wrote: > > Sebastian Hetze wrote: > >> Hi * > >> > >> attached you find a patch that adds new options --subject_cn and > >> --subject_mail to ipa-server-install that make the CA cert subject CN > >> customizable. > >> > >> This patch has been tested by a customer in a PoC. > >> However, i assume additional testing in different environments is > >> required. > >> > >> It would be greatly appreciated if this patch would find its way into > >> the product very soon. > > > > I don't see the advantage of passing around the subject_rdn along with > > the base. Why not pre-combine them into a DN? > Think of the subject_rdn as given name for the CA cert and the > subject_base as family name for all subsequent service certs that IPA > automatically generates and signs. While the given names for the > generated service certs may stay hard coded, only the given name for the > CA cert needs to be customizable as requested in the RFE. > Look into the source and you will see that subject_base is used all over > the place and subject_rdn (as replacement for the hard coded > "CN=Certificate Authority") only related to the CA cert. They need to be > kept separate. > In your patch, subject_rdn is used in few places where it is passed around. I agree with Rob; in the handful of places where the full DN is formed (currently by prepending "CN=Certificate Authority"), we should pass in the full DN. > > > > > > Similarly, I think I'd drop storing the subject base and RDN and just > > store just the DN. I don't think there would be any backwards compat > > issues as this would only apply to new installs. > > > > I think this would explode the number of options as users request > > additional attributes for the subject (OU, C, etc). Might be better to > > make the user pass in a full DN if they want to manage the CA subject. > > I don't know if any validation would be required for dogtag (e.g. is > > there a minimum set of components needed?) > CN is mandatory and only emailAddress is a commonly used option for the > "given name" subject_rdn. OU, C and alike belong to the subject_base. > Let us not add new arguments. We should enhance --subject instead. Existing behaviour: - ``--subject`` gives subject base. If not given, defaults to "O=$REALM". - "CN=Certificate Authority" prepended to subject base to form full subject DN. - Dogtag requires that the CA Subject DN starts with CN. My proposal for augmented behaviour: - If ``--subject`` not given, existing behaviour retained. - If ``--subject`` supplied: 1. Extract O, OU, C, L, ST and DC components from argument (order preserved) to form the subject base. If argument contains none of these attributes, subject base is defaulted to "O=$REALM" (per current behaviour) and appended to the CA Subject DN. 2. If argument contains CN but it is not the "most specific" RDN, move it to the front (to satisfy requirement of Dogtag profile). 3. If argument does not contain CN, prepend "CN=Certificate Authortiy" per existing behaviour. 4. Apart from (1), (2) and (3), CA Subject DN stays otherwise unchanged, therefore Email Address (E) is supported. Sebastian, would this scheme meet your customer's requirements? I also note, in your patch, that you define method DsInstance.find_subject_rdn() but it is not used. What is the purpose of this method? Thank you for providing this patch and pushing forward on this RFE. If you are happy with my above proposal I'm happy to take ownership and get this over this line. Cheers, Fraser > > > > rob > > Beste Grüße / Best regards > Sebastian Hetze > -- > Senior Solution Architect > Red Hat GmbH. Niederlassung Berlin > Am Treptower Park 75 12435 Berlin > Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 > Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL
On Tue, Jun 28, 2016 at 01:47:23PM -, freeipa wrote: > #6002: Default CA can be used without an ACL > > Comment (by ftweedal): > > This is expected behaviour; if a CA ACL does not reference any CAs, > and does not have cacat=all, then it is assumed to refer to the > default CA. This is for backwards compatibility with existing > CA ACLs, which do not reference any CAs but did (and still do) > allow access to IPA CA. > > Leaving open for discussion about whether to break compatibility > for a more consistent behaviour. > Didn't get any feedback in the ticket yet so raising on list for visibility. If people agree with current behaviour I can add a clarification to caacl plugin help text and close out this ticket. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [patch 0038-0040] Sub CA test patches
On Fri, Jul 01, 2016 at 03:57:29PM +0200, Milan Kubík wrote: > On 06/27/2016 01:31 PM, Milan Kubík wrote: > > On 06/27/2016 02:57 AM, Fraser Tweedale wrote: > > > On Fri, Jun 24, 2016 at 12:08:24PM +0200, Milan Kubík wrote: > > > > On 06/24/2016 03:42 AM, Fraser Tweedale wrote: > > > > > On Tue, Jun 21, 2016 at 05:01:35PM +0200, Milan Kubík wrote: > > > > > > Hi Fraser and list, > > > > > > > > > > > > I have made changes to the test plan on the wiki [1] according to > > > > > > the > > > > > > information in "[Testplan review] Sub CAs" thread. > > > > > > > > > > > > I also implemented the tests in the test plan: > > > > > > > > > > > > patch 0038 - CATracker and CA CRUD test > > > > > > patch 0039 - extension to CA ACL test > > > > > > patch 0040 - functional test with ACLs and certificate > > > > > > profile, reusing my > > > > > > previous S/MIME based tests. This patch also tests for > > > > > > the cert-request > > > > > > behavior when profile ID or CA cn are ommited. > > > > > > > > > > > > The tests ATM do not verify the Issuer name in the > > > > > > certificate itself, just > > > > > > from the ipa entry of the certificate. > > > > > > > > > > > The approach you are using:: > > > > > > > > > > assert cert_info['result']['issuer'] == > > > > > smime_signing_ca.ipasubjectdn > > > > > > > > > > is not quite as you describe (these are virtual attributes, not > > > > > attributes of an actual entry); but the approach is valid. > > > > The issue then is in the wording? The other approach I could > > > > have used here > > > > is to retrieve the two certificates and compare the fields manually. > > > > Are these virtual attributes created from the certificate itself? > > > > > > > That's correct. > > > > > > > > > Fraser, could you please verify my reasoning behind the > > > > > > test cases for > > > > > > cert-request in the patch 40? > > > > > > > > > > > The tests look OK. With the default CA / default profiles, is there > > > > > appropriate isolation between test cases to ensure that if, e.g. > > > > > some other test case adds/modifies CA ACLs such that these > > > > > expected-to-fail tests now pass, that this does not affect the > > > > > TestCertSignMIMEwithSubCA test case? > > > > > > > > > > Thanks, > > > > > Fraser > > > > The ACL, SMIME CA and S/MIME profile lifetime is constrained by > > > > the class > > > > scope > > > > enforced by pytest. > > > > The two test cases depend on the fact documented in the designs > > > > and that is > > > > what > > > > cert-request fallbacks to when CA or profile ID are not provided. > > > > Unless something changes caIPAserviceCert profile or affiliated > > > > ACL, then > > > > the test cases > > > > are safe. > > > > > > > If you have thought about possible interference from other tests, I > > > am happy. > > > > > > Note another problematic scenario: what if a different (preceding) > > > test adds a CA ACL that would allow the requests that you expect to > > > fail? Just something to think about :) > > > > > > Thanks, > > > Fraser > > Then the failure would be problem of the preceding test and we would > > need to fix it. We are dealing with test side effects > > in other parts of the execution already... > > > > The test is constructed in a way that isolates it (to a certain degree) > > by the mechanisms available > > in pytest. Of course I cannot make the test future-proof or guarantee > > that a bug in some other test > > will not affect the execution of other tests as they all run against one > > IPA instance. > > I do not think, however, that potential misbehaving test case that will > > interfere > > should prevent us from implementing this and similar test cases. > > > > If you have some specific issue that is in the patch, I'm happy to fix > > them. > > > > I will try to think more about corner ca
[Freeipa-devel] [PATCH] 0087 uninstall: untrack lightweight CA certs
The attached patch fixes
https://fedorahosted.org/freeipa/ticket/6020
Thanks,
Fraser
From 15cca8e108c6d47a647cbc1dc647dcecbf334b9d Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Mon, 4 Jul 2016 13:05:28 +1000
Subject: [PATCH] uninstall: untrack lightweight CA certs
Fixes: https://fedorahosted.org/freeipa/ticket/6020
---
ipaserver/install/cainstance.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index
5e3e8c7f9a1845b82d23de589f804aa065387b38..070498fe8a394802ea55f848a268e2b6563ec472
100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1127,6 +1127,12 @@ class CAInstance(DogtagInstance):
"""
super(CAInstance, self).stop_tracking_certificates(False)
+# stop tracking lightweight CA signing certs
+for request_id in certmonger.get_requests_for_dir(self.nss_db):
+nickname = certmonger.get_request_value(request_id, 'key-nickname')
+if nickname.startswith('caSigningCert cert-pki-ca '):
+certmonger.stop_tracking(self.nss_db, nickname=nickname)
+
try:
certmonger.stop_tracking(paths.HTTPD_ALIAS_DIR, nickname='ipaCert')
except RuntimeError as e:
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status
On Fri, Jul 01, 2016 at 10:05:48AM +0200, Jan Cholasta wrote: > On 1.7.2016 08:57, Jan Cholasta wrote: > > On 1.7.2016 06:54, Jan Cholasta wrote: > > > On 1.7.2016 06:47, Fraser Tweedale wrote: > > > > On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: > > > > > On 29.6.2016 12:18, Jan Cholasta wrote: > > > > > > On 29.6.2016 10:47, Fraser Tweedale wrote: > > > > > > > On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 29.6.2016 06:11, Fraser Tweedale wrote: > > > > > > > > > Dear team, > > > > > > > > > > > > > > > > > > The attached patch implements the --ca option for the rest of > > > > > > > > > the > > > > > > > > > cert-blah commands > > > > > > > > > (https://fedorahosted.org/freeipa/ticket/5999). > > > > > > > > > > > > > > > > 1) I don't think cert-status should be treated specially. The > > > > > > > > operation to > > > > > > > > check status of a certificate request is not specific to Dogtag. > > > > > > > > > > > > > > > I'm happy to add the option, with the caveat that because (of top > > > > > > > of > > > > > > > head) there is not (yet) a way in Dogtag to distinguish/filter > > > > > > > requests by target CA, value may go unused. > > > > > > > > > > > > IMO that's OK, since it's a safe non-descructive operation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) cert-show is called twice in cert-revoke. Can we call it just > > > > > > > > once? > > > > > > > > > > > > > > > I'll address this in next patchset. > > > > > > > > > > > > OK. > > > > > > > > > > ACK on the first version of the patch, since it's better than > > > > > nothing. The > > > > > ticket remains open, please fix the rest ASAP. > > > > > > > > > > Added VERSION bump and pushed to master: > > > > > ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e > > > > > > > > > > Honza > > > > > > > > > New patch 0086 attached, adding the option to cert-status command. > > > > > > Thanks. We could at least check if the specified CA exists, couldn't we? > > > > To speed things up, I have updated your patch with this, see the > > attachment. > > > > If the change looks good to you, we can push the patch. > > Your original patch works for me, ACK. My change can be pushed under the > one-liner rule, so pushing them combined in the modified patch. > > Pushed to master: 4844eaec197690e21c6cf44743df7f456d0e185d > Jan, thanks for pushing that along. My WIP was much the same, but I got bitten by stale API schema on client side and it did not know about the --ca option. I revisited it tonight, but by then you had pushed the commit :) Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0070..0071 Fix replica installation from IPA v4.2
On Fri, Jul 01, 2016 at 08:36:29AM +0200, Stanislav Laznicka wrote: > On 06/17/2016 08:59 AM, Fraser Tweedale wrote: > > The attached patches fix > > https://fedorahosted.org/freeipa/ticket/5963 > > > > Thanks Milan for reporting. > > > > Cheers, > > Fraser > > > Tried this patch on 4.4 with domain level set to 0 and it does fix the issue > for me so ACK for 4.4. > > Not sure if this is going to be backported but if so, both patches will need > modifications for 4.2 and the latter patch will require modifications for > 4.3 for them to apply. > Thanks for testing! It is only needed for 4.4. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status
On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote:
> On 29.6.2016 12:18, Jan Cholasta wrote:
> > On 29.6.2016 10:47, Fraser Tweedale wrote:
> > > On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote:
> > > > Hi,
> > > >
> > > > On 29.6.2016 06:11, Fraser Tweedale wrote:
> > > > > Dear team,
> > > > >
> > > > > The attached patch implements the --ca option for the rest of the
> > > > > cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999).
> > > >
> > > > 1) I don't think cert-status should be treated specially. The
> > > > operation to
> > > > check status of a certificate request is not specific to Dogtag.
> > > >
> > > I'm happy to add the option, with the caveat that because (of top of
> > > head) there is not (yet) a way in Dogtag to distinguish/filter
> > > requests by target CA, value may go unused.
> >
> > IMO that's OK, since it's a safe non-descructive operation.
> >
> > >
> > > >
> > > > 2) cert-show is called twice in cert-revoke. Can we call it just once?
> > > >
> > > I'll address this in next patchset.
> >
> > OK.
>
> ACK on the first version of the patch, since it's better than nothing. The
> ticket remains open, please fix the rest ASAP.
>
> Added VERSION bump and pushed to master:
> ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e
>
> Honza
>
New patch 0086 attached, adding the option to cert-status command.
(2) will be addressed later due to conflicts with other patches (or
maybe as part of those other patches).
Thanks,
Fraser
From b4d49da637035cdd8b4504b09b9790b3fc68c144 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Fri, 1 Jul 2016 14:42:37 +1000
Subject: [PATCH] Add --cn option to cert-status
Add the 'cacn' option to the cert-status command. Right now there
is nothing we need to (or can) do with it, but we add it anyway for
future use.
Fixes: https://fedorahosted.org/freeipa/ticket/5999
---
API.txt | 3 ++-
VERSION | 4 ++--
ipaserver/plugins/cert.py | 14 ++
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/API.txt b/API.txt
index
c01692e17dc1ed368c14e32ab7e3fc09bc4d1ffc..9f9456d2cefac9c31ff89f3812a862a80e7ad307
100644
--- a/API.txt
+++ b/API.txt
@@ -799,9 +799,10 @@ output: Entry('result')
output: Output('summary', type=[, ])
output: PrimaryKey('value')
command: cert_status/1
-args: 1,3,3
+args: 1,4,3
arg: Int('request_id')
option: Flag('all', autofill=True, cli_name='all', default=False)
+option: Str('cacn?', autofill=True, cli_name='ca', default=u'ipa')
option: Flag('raw', autofill=True, cli_name='raw', default=False)
option: Str('version?')
output: Entry('result')
diff --git a/VERSION b/VERSION
index
23ceecc98e6ecf9adc21016508ba9feaa1454e6f..212b7d740a12a313395faf3bcdefaf09c41651f9
100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=205
-# Last change: Add --ca option to cert-revoke and cert-remove-hold
+IPA_API_VERSION_MINOR=206
+# Last change: Add --ca option to cert-status
diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py
index
817bdc26f1d8b53a323802079d19e367404528bd..70add0bb38a08ec030969dce6369cde85a33a5fb
100644
--- a/ipaserver/plugins/cert.py
+++ b/ipaserver/plugins/cert.py
@@ -638,17 +638,15 @@ class cert_status(Retrieve, BaseCertMethod,
VirtualCommand):
operation = "certificate status"
-def get_options(self):
-for option in super(cert_status, self).get_options():
-if option.name == 'cacn':
-# Dogtag requests are uniquely identified by their
-# number; there is no need to distinguish by CA.
-continue
-yield option
-
def execute(self, request_id, **kw):
ca_enabled_check()
self.check_access()
+
+# Dogtag requests are uniquely identified by their number;
+# furthermore, Dogtag (as at v10.3.4) does not report the
+# target CA in request data, so we cannot check. So for
+# now, there is nothing we can do with the 'cacn' option.
+
return dict(
result=self.Backend.ra.check_request_status(str(request_id)),
value=pkey_to_value(request_id, kw),
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0082 cert-request: better error msg when 'add' not supported
On Thu, Jun 30, 2016 at 07:49:04PM +1000, Fraser Tweedale wrote:
> On Thu, Jun 30, 2016 at 11:38:35AM +0200, Florence Blanc-Renaud wrote:
> > On 06/30/2016 06:29 AM, Fraser Tweedale wrote:
> > > On Wed, Jun 29, 2016 at 11:30:14AM +0200, Florence Blanc-Renaud wrote:
> > > > On 06/29/2016 07:25 AM, Fraser Tweedale wrote:
> > > > > The attached patch fixes
> > > > > https://fedorahosted.org/freeipa/ticket/5991.
> > > > >
> > > > > Thanks,
> > > > > Fraser
> > > > >
> > > > >
> > > > >
> > > > Hi Fraser,
> > > >
> > > > A few cosmetic comments:
> > > >
> > > > PEP8 issues:
> > > > ./ipalib/errors.py:1399:1: E302 expected 2 blank lines, found 1
> > > > ./ipaserver/plugins/cert.py:394:80: E501 line too long (98 > 79
> > > > characters)
> > > > ./ipaserver/plugins/cert.py:496:80: E501 line too long (81 > 79
> > > > characters)
> > > >
> > > > and there is a typo in ipaserver/plugins/cert.py
> > > > +doc=_("automatically add the principal if it doesn't exist
> > > > (service princpals only)"),
> > > >
> > > > should be "princ*i*pals only"
> > > >
> > > > Otherwise LGTM,
> > > > Flo
> > > >
> > > Thanks for review, Flo. Updated patch attached.
> > >
> > > Cheers,
> > > Fraser
> > >
> > Hi Fraser,
> >
> > thanks for updated patch. There is still a pep8 error:
> > ./ipalib/errors.py:1399:1: E302 expected 2 blank lines, found 1
> >
> Whups!
>
> > I am also wondering if the message is clear enough. When running the CLI
> > it's ok because the user typed --add, but the GUI displays "'add' is not
> > supported for user principals"
> > and I feel
> > "'add' option is not supported for user principals"
> > would be more user-friendly. What do you think?
> >
> Yes, I concur that mentioning "option" is an improvement. Will cut
> a new patch shortly
>
> Thanks!
> Fraser
>
Updated patch attached. Third time's the charm? ;)
Cheers,
Fraser
From 99c1d5c32b19a070f5e995fce4de32dee39433c1 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Wed, 29 Jun 2016 15:02:51 +1000
Subject: [PATCH] cert-request: better error msg when 'add' not supported
cert-request supports adding service principals that don't exist.
If add is requested for other principal types, the error message
just says "the principal doesn't exist".
Add a new error type with better error message to explain that 'add'
is not supported for host or user principals.
Fixes: https://fedorahosted.org/freeipa/ticket/5991
---
ipalib/errors.py | 10 ++
ipaserver/plugins/cert.py | 21 ++---
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/ipalib/errors.py b/ipalib/errors.py
index
10491a94211648df8bda60f3dbc9e52d19e83d10..7b4f15dd60ee80719195ba1b9b85d075b10bdf4f
100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1397,6 +1397,16 @@ class ServerRemovalError(ExecutionError):
format = _('Server removal aborted: %(reason)s.')
+class OperationNotSupportedForPrincipalType(ExecutionError):
+"""
+**4034** Raised when an operation is not supported for a principal type
+"""
+
+errno = 4034
+format = _(
+'%(operation)s is not supported for %(principal_type)s principals')
+
+
class BuiltinError(ExecutionError):
"""
**4100** Base class for builtin execution errors (*4100 - 4199*).
diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py
index
63351c54c134f2bd58e8eb18bb0dc3bc6a5734b3..526360bb6b777abd398ad6d5e63f040fb52ac529
100644
--- a/ipaserver/plugins/cert.py
+++ b/ipaserver/plugins/cert.py
@@ -145,6 +145,12 @@ http://www.ietf.org/rfc/rfc5280.txt
USER, HOST, SERVICE = range(3)
+PRINCIPAL_TYPE_STRING_MAP = {
+USER: _('user'),
+HOST: _('host'),
+SERVICE: _('service'),
+}
+
register = Registry()
PKIDATE_FORMAT = '%Y-%m-%d'
@@ -385,7 +391,9 @@ class cert_request(Create, BaseCertMethod, VirtualCommand):
),
Flag(
'add',
-doc=_("automatically add the principal if it doesn't exist"),
+doc=_(
+"automatically add the principal if it doesn't exist "
+"(service principals only)"),
),
)
@@ -480,8 +488,15 @@ class cert_request(Create, BaseCertMethod, VirtualCommand):
elif principal_type == USER:
[Freeipa-devel] [PATCH] 0085 Fix upgrade when Dogtag also upgraded from 10.2 -> 10.3
Hullo,
The attached patch fixes
https://fedorahosted.org/freeipa/ticket/6011.
Cheers,
Fraser
From c92ed38c0ef41814dec6ddf4a003948af5bc0beb Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 30 Jun 2016 21:01:07 +1000
Subject: [PATCH] Fix upgrade when Dogtag also upgraded from 10.2 -> 10.3
ipa-server-upgrade from pre-lightweight CAs version fails when
Dogtag is also being upgraded from pre-lightweight CAs version,
because Dogtag needs to be restarted after adding the lightweight
CAs container, before requesting information about the host
authority.
Move the addition of the Dogtag lightweight CAs container entry a
bit earlier in the upgrade procedure, ensuring restart.
Fixes: https://fedorahosted.org/freeipa/ticket/6011
---
ipaserver/install/cainstance.py | 14 +++---
ipaserver/install/server/upgrade.py | 2 +-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index
ef69c898bcd4f9d8d7e698b04117047a33c1e45f..28f8fe156ff828fdcfafdf602fa6675a4ee84fea
100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1695,7 +1695,7 @@ def ensure_ldap_profiles_container():
)
def ensure_lightweight_cas_container():
-ensure_entry(
+return ensure_entry(
DN(('ou', 'authorities'), ('ou', 'ca'), ('o', 'ipaca')),
objectclass=['top', 'organizationalUnit'],
ou=['authorities'],
@@ -1703,6 +1703,12 @@ def ensure_lightweight_cas_container():
def ensure_entry(dn, **attrs):
+"""Ensure an entry exists.
+
+If an entry with the given DN already exists, return ``False``,
+otherwise add the entry and return ``True``.
+
+"""
server_id = installutils.realm_to_serverid(api.env.realm)
dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id
@@ -1712,12 +1718,14 @@ def ensure_entry(dn, **attrs):
try:
conn.get_entry(dn)
+return False
except errors.NotFound:
# entry doesn't exist; add it
entry = conn.make_entry(dn, **attrs)
conn.add_entry(entry)
-
-conn.disconnect()
+return True
+finally:
+conn.disconnect()
def configure_profiles_acl():
diff --git a/ipaserver/install/server/upgrade.py
b/ipaserver/install/server/upgrade.py
index
3955a8cb9faf8e5c3350fc3912ea9f05a4b97719..43427178b11f63797a9537eadee836d7cf224311
100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -1747,6 +1747,7 @@ def upgrade_configuration():
ca_enable_pkix(ca),
ca_configure_profiles_acl(ca),
ca_configure_lightweight_ca_acls(ca),
+ca_ensure_lightweight_cas_container(ca),
ca_add_default_ocsp_uri(ca),
])
@@ -1758,7 +1759,6 @@ def upgrade_configuration():
except ipautil.CalledProcessError as e:
root_logger.error("Failed to restart %s: %s", ca.service_name, e)
-ca_ensure_lightweight_cas_container(ca)
ca_enable_ldap_profile_subsystem(ca)
# This step MUST be done after ca_enable_ldap_profile_subsystem and
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0082 cert-request: better error msg when 'add' not supported
On Thu, Jun 30, 2016 at 11:38:35AM +0200, Florence Blanc-Renaud wrote:
> On 06/30/2016 06:29 AM, Fraser Tweedale wrote:
> > On Wed, Jun 29, 2016 at 11:30:14AM +0200, Florence Blanc-Renaud wrote:
> > > On 06/29/2016 07:25 AM, Fraser Tweedale wrote:
> > > > The attached patch fixes
> > > > https://fedorahosted.org/freeipa/ticket/5991.
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> > > >
> > > >
> > > Hi Fraser,
> > >
> > > A few cosmetic comments:
> > >
> > > PEP8 issues:
> > > ./ipalib/errors.py:1399:1: E302 expected 2 blank lines, found 1
> > > ./ipaserver/plugins/cert.py:394:80: E501 line too long (98 > 79
> > > characters)
> > > ./ipaserver/plugins/cert.py:496:80: E501 line too long (81 > 79
> > > characters)
> > >
> > > and there is a typo in ipaserver/plugins/cert.py
> > > +doc=_("automatically add the principal if it doesn't exist
> > > (service princpals only)"),
> > >
> > > should be "princ*i*pals only"
> > >
> > > Otherwise LGTM,
> > > Flo
> > >
> > Thanks for review, Flo. Updated patch attached.
> >
> > Cheers,
> > Fraser
> >
> Hi Fraser,
>
> thanks for updated patch. There is still a pep8 error:
> ./ipalib/errors.py:1399:1: E302 expected 2 blank lines, found 1
>
Whups!
> I am also wondering if the message is clear enough. When running the CLI
> it's ok because the user typed --add, but the GUI displays "'add' is not
> supported for user principals"
> and I feel
> "'add' option is not supported for user principals"
> would be more user-friendly. What do you think?
>
Yes, I concur that mentioning "option" is an improvement. Will cut
a new patch shortly
Thanks!
Fraser
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0083 Fix regression on ipa-4-3 branch
The attached patch fixes a regression on the ipa-4-3 branch, caused
by commit 3d71c43504ea7837ea14bb9dd4a469c07337293f.
Thanks,
Fraser
From 4d4c62a2c26affb82a7f2e40f36ad0de66beabf9 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftwee...@redhat.com>
Date: Thu, 30 Jun 2016 14:30:30 +1000
Subject: [PATCH] Move normalize_hostname to where it is expected
Commit 3d71c43504ea7837ea14bb9dd4a469c07337293f broke
ipa-client-install by importing normalize_hostname from the wrong
module. Move the function.
https://fedorahosted.org/freeipa/ticket/5976
---
ipalib/plugins/host.py | 10 +-
ipalib/util.py | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py
index
3fe9c5f9cace71210125371b0aa891490a3dca99..0bb5a535bddfbd3032ab91e410ec6d4fa33f889f
100644
--- a/ipalib/plugins/host.py
+++ b/ipalib/plugins/host.py
@@ -44,7 +44,7 @@ from ipalib import x509
from ipalib import output
from ipalib.request import context
from ipalib.util import (normalize_sshpubkey, validate_sshpubkey_no_options,
-convert_sshpubkey_post, validate_hostname)
+convert_sshpubkey_post, validate_hostname, normalize_hostname)
from ipapython.ipautil import ipa_generate_password, CheckedIPAddress
from ipapython.dnsutil import DNSName
from ipapython.ssh import SSHPublicKey
@@ -267,14 +267,6 @@ def validate_ipaddr(ugettext, ipaddr):
return None
-def normalize_hostname(hostname):
-"""Use common fqdn form without the trailing dot"""
-if hostname.endswith(u'.'):
-hostname = hostname[:-1]
-hostname = hostname.lower()
-return hostname
-
-
def _hostname_validator(ugettext, value):
try:
validate_hostname(value)
diff --git a/ipalib/util.py b/ipalib/util.py
index
7a991490f76694261deda995ea138f35cf73a1f6..6caf3962d354292834a6ff7bdec424f1df1975e7
100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -844,3 +844,11 @@ def detect_dns_zone_realm_type(api, domain):
def has_managed_topology(api):
domainlevel = api.Command['domainlevel_get']().get('result',
DOMAIN_LEVEL_0)
return domainlevel > DOMAIN_LEVEL_0
+
+
+def normalize_hostname(hostname):
+"""Use common fqdn form without the trailing dot"""
+if hostname.endswith(u'.'):
+hostname = hostname[:-1]
+hostname = hostname.lower()
+return hostname
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0081 Add --ca option to cert-revoke and cert-remove-hold
On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: > Hi, > > On 29.6.2016 06:11, Fraser Tweedale wrote: > > Dear team, > > > > The attached patch implements the --ca option for the rest of the > > cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). > > 1) I don't think cert-status should be treated specially. The operation to > check status of a certificate request is not specific to Dogtag. > I'm happy to add the option, with the caveat that because (of top of head) there is not (yet) a way in Dogtag to distinguish/filter requests by target CA, value may go unused. > > 2) cert-show is called twice in cert-revoke. Can we call it just once? > I'll address this in next patchset. Thanks for reviewing! Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
