Re: [Freeipa-users] Getting a certificate for an alias

[Fraser Tweedale]

On Thu, May 04, 2017 at 10:30:39PM -0400, Steve Huston wrote:
> On Thu, May 4, 2017 at 9:15 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> > The fix for this was released in FreeIPA 4.5.  See ticket
> > https://pagure.io/freeipa/issue/6295.
> >
> 
> Excellent!  Any chance of that getting backported into the 4.4.x
> series available on RHEL7?
> 
Anecdotally it's unlikely, but it cannot hurt to file a ticket /
support case and ask for it.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Getting a certificate for an alias

[Fraser Tweedale]

On Thu, May 04, 2017 at 05:36:26PM -0400, Steve Huston wrote:
> I'm trying to use certmonger to get an SSL certificate on a web host
> which has an alias.  I added the alias as a principal alias to the
> host record in FreeIPA, and I added the service as well with the
> actual hostname and the alias.  However every time certmonger contacts
> the CA, the request is rejected with "The service principal for
> subject alt name ... does not exist" (or earlier, another similar
> error which has now been lost to the scrollback).
> 
> hostname: coathook.astro.princeton.edu
> Principal alias: host/coathook.astro.princeton@astro.princeton.edu
> Principal alias: host/puppet.astro.princeton@astro.princeton.edu
> 
> Principal alias: HTTP/coathook.astro.princeton@astro.princeton.edu
> Principal alias: HTTP/puppet.astro.princeton@astro.princeton.edu
> Service: HTTP
> Host Name: coathook.astro.princeton.edu
> 
> ipa-getcert request -k /etc/pki/tls/private/puppetexplorer.key -f
> /etc/pki/tls/certs/puppetexplorer.crt -D puppet.astro.princeton.edu -N
> CN=coathook.astro.princeton.edu,O=ASTRO.PRINCETON.EDU -K
> HTTP/coathook.astro.princeton@astro.princeton.edu -C
> '/usr/sbin/apachectl graceful'
> 
> When I check with ipa-getcert list, I find:
> ca-error: Server at https://ipa.astro.princeton.edu/ipa/xml
> failed request, will retry: 4001 (RPC failed at server.  The service
> principal for subject alt name puppet.astro.princeton.edu in
> certificate request does not exist).
> 
> Other attempts used the CN of puppet, and the Kerberos principal of
> puppet as well, and they also failed but with the slightly different
> error (I believe it was that the host does not exist).
> 
> So how does one create a certificate for an alias on a host?
> 
Hi Steve,

The fix for this was released in FreeIPA 4.5.  See ticket
https://pagure.io/freeipa/issue/6295.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] External cert with correct CSR?

[Fraser Tweedale]

On Tue, May 02, 2017 at 11:10:12AM -0500, Kat wrote:
> Yeah, after I sent this email, I realized what I was trying to do and that,
> "Oh wait, this is not really going to work."
> 
Indeed.  This feature is usually used to chain an IPA CA into an
organisation's existing PKI, which is controlled by the
organisation, thus they can add whatever they need to the cert
regardless of what is/is not asserted by the CSR).

Cheers,
Fraser

> For what it is worth - version on RHEL 7.3 - 4.4.0-14.el7_3.7
> 
> -K
> 
> On 5/2/17 11:04 AM, Rob Crittenden wrote:
> > Kat wrote:
> > > Hi all,
> > > 
> > > I am somewhat confused trying to get the process of using an external
> > > cert for IPA.
> > > 
> > > If I follow step 1:
> > > ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.COM
> > > --external-ca -U
> > > 
> > > This does indeed generate a CSR, but trying to do anything with this CSR
> > > has no success since it is not properly formed with all info.  In
> > > otherwords, ipa does not add country, state, location, etc. If I submit
> > > this CSR to any cert company, it will of course, complain. Is there a
> > > way to get this right? Or am I just missing something here?
> > > 
> > What cert company are you trying to get to sign this? This is a CA cert,
> > I don't know that any of the major ones will sign this, at least not
> > without a huge check.
> > 
> > What version of IPA?
> > 
> > rob
> > 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] how to setup freeipa project to local environment

[Fraser Tweedale]

On Fri, Apr 28, 2017 at 10:41:29AM +0530, rajkumar wrote:
> Hello freeipa team,
> 
> I have download freeipa4.4.4.tar.gz and I need to setup  freeipa project as
> a local environment(to customize via IDE like eclipse) for customization.
> suggest me how can do that. or any reference link.
> 
> Thanks,
> 
Instructions for building FreeIPA from source (on Red Hat-flavoured
distros, at least) are here: http://www.freeipa.org/page/Build

If you think your work may be useful to other please engage with
upstream development on IRC (#freenode), mailing list
(freeipa-de...@redhat.com) and GitHub (freeipa/freeipa).

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to customized freeipa certificate form

[Fraser Tweedale]

On Thu, Apr 27, 2017 at 12:02:56PM +0530, rajkumar wrote:
> Hello Fraser,
> 
> Ok, I got similar fields,  MD5 Fingerprint and Sha1 Fingerprint value in
> certificate form in freeipa, But it values are disabled in certificate form
> in webui. suggest me how can I enable these values via webui or any other
> way.
> 
> *Reference: * https://pagure.io/freeipa/issue/6903
> 
> Thanks,
> 
Ah, I think I understand now.  You just need the existing fields to
be populated properly?  Yes, it appears to be a bug that these are
not filled out.

Thank you for reporting the issue in the bug tracker.  Could you
please indicate what version of FreeIPA you are using?

Cheers,
Fraser

> 
> On 04/27/2017 11:49 AM, Fraser Tweedale wrote:
> > On Thu, Apr 27, 2017 at 10:16:15AM +0530, rajkumar wrote:
> > > Hello Fraser,
> > > 
> > > Thanks for your quick reply, I need to add hash value field in certificate
> > > details form and write a code to get hash value of create certificated and
> > > viewed to that hash value field. Suggest me How can I do this. and also
> > > suggest latest source of freeipa.
> > > 
> > The UI will only show information from within the certificate
> > itself, or immutable metadata about it.  Do you mean that you want
> > to see a digest of the certificate?  If not, could you be more clear
> > about exactly what data you need to see, and how it is derived from
> > the certificate?
> > 
> > If you want to set your own data into the cert when issuing it,
> > could you be more clear about what data exactly, and how you want it
> > to appear in the certificate?
> > 
> > Thanks,
> > Fraser
> > 
> > > 
> > > On 04/27/2017 08:13 AM, Fraser Tweedale wrote:
> > > > On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote:
> > > > > Hello Freeipa Team,
> > > > > 
> > > > > I am new to freeipa, I have installed freeipa for generate 
> > > > > certificate for
> > > > > our products, I have generated certificates, its works fine, but I 
> > > > > need to
> > > > > customized freeipa certificate form for add more fields. Suggest me 
> > > > > how can
> > > > > I achieve this?
> > > > > 
> > > > > Reference: please find the attachment of certificate form. I need to 
> > > > > add
> > > > > more fields to that form.
> > > > > 
> > > > What is your use case?
> > > > 
> > > > I suspect (but please clarify) that it does not really matter to you
> > > > what fields we display in the UI, but rather, what is actually in
> > > > the certificate.  Could you please clarify:
> > > > 
> > > > 1. What you actually need put into the certificate(s)
> > > > 
> > > > 2. What you want displayed when viewing a cert in the Web UI, that
> > > >  is not currently displayed.
> > > > 
> > > > Thanks,
> > > > Fraser
> > > -- 
> > > Regards,
> > > Rajkumar E
> > > r...@gworks.mobi
> > > 8675496254.
> > > 
> 
> -- 
> Regards,
> Rajkumar E
> r...@gworks.mobi
> 8675496254.
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to customized freeipa certificate form

[Fraser Tweedale]

On Thu, Apr 27, 2017 at 10:16:15AM +0530, rajkumar wrote:
> Hello Fraser,
> 
> Thanks for your quick reply, I need to add hash value field in certificate
> details form and write a code to get hash value of create certificated and
> viewed to that hash value field. Suggest me How can I do this. and also
> suggest latest source of freeipa.
> 
The UI will only show information from within the certificate
itself, or immutable metadata about it.  Do you mean that you want
to see a digest of the certificate?  If not, could you be more clear
about exactly what data you need to see, and how it is derived from
the certificate?

If you want to set your own data into the cert when issuing it,
could you be more clear about what data exactly, and how you want it
to appear in the certificate?

Thanks,
Fraser

> 
> 
> On 04/27/2017 08:13 AM, Fraser Tweedale wrote:
> > On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote:
> > > Hello Freeipa Team,
> > > 
> > > I am new to freeipa, I have installed freeipa for generate certificate for
> > > our products, I have generated certificates, its works fine, but I need to
> > > customized freeipa certificate form for add more fields. Suggest me how 
> > > can
> > > I achieve this?
> > > 
> > > Reference: please find the attachment of certificate form. I need to add
> > > more fields to that form.
> > > 
> > What is your use case?
> > 
> > I suspect (but please clarify) that it does not really matter to you
> > what fields we display in the UI, but rather, what is actually in
> > the certificate.  Could you please clarify:
> > 
> > 1. What you actually need put into the certificate(s)
> > 
> > 2. What you want displayed when viewing a cert in the Web UI, that
> > is not currently displayed.
> > 
> > Thanks,
> > Fraser
> 
> -- 
> Regards,
> Rajkumar E
> r...@gworks.mobi
> 8675496254.
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to customized freeipa certificate form

[Fraser Tweedale]

On Wed, Apr 26, 2017 at 07:02:08PM +0530, rajkumar wrote:
> Hello Freeipa Team,
> 
> I am new to freeipa, I have installed freeipa for generate certificate for
> our products, I have generated certificates, its works fine, but I need to
> customized freeipa certificate form for add more fields. Suggest me how can
> I achieve this?
> 
> Reference: please find the attachment of certificate form. I need to add
> more fields to that form.
> 
What is your use case?

I suspect (but please clarify) that it does not really matter to you
what fields we display in the UI, but rather, what is actually in
the certificate.  Could you please clarify:

1. What you actually need put into the certificate(s)

2. What you want displayed when viewing a cert in the Web UI, that
   is not currently displayed.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Signed cert/CA and updating certs?

[Fraser Tweedale]

On Wed, Apr 26, 2017 at 09:51:34AM -0500, Kat wrote:
> Hi again,
> 
> Well, Let's Encrypt is working nicely with the httpd cert - but I am
> wondering if there is a way to use Let's Encrypt or another signed cert to
> replace the CA to be able to sign all the certs with it, or is the only way
> to sign our certs with the built in CA?  I guess, thinking about it more, if
> I am signing certs based on LE's Cert, that might be a bad thing from their
> standpoint...
> 
> Just thinking out loud and looking for some input.
> 
> Kat
> 

LE issues TLS server certificates and uses the ACME protocol for
automated domain validation and certificate issuance.  For IPA,
there is no way (in general) that we can satisfy the DV challenges,
and LE issues certs in a single profile for a narrow use case.

So the general answer is: LE is not a suitable CA "backend" for IPA
cert issuance.

That said, there is some scope for acquisition of certs from LE for
IPA-enrolled TLS servers.  We can manage it if IPA's DNS is publicly
exposed.  But we have not implemented this and it is not a priority.

HTH.  Let me know if you have further questions.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Fraser Tweedale]

On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
> Thank you. That worked for the master. How do I fix the replica's cert ?
> This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
> ipa's DNS at all. Did this happen because of that ?
> 
This is not related to DNS.

To fix the replica, log onto the host and perform the same steps
with Certmonger there.  The tracking Request ID will be different
but otherwise the process is the same.

Cheers,
Fraser

> On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> > > I can confirm that I see this behaviour too. My ipa server install is a
> > > pretty stock install with no 3rd party certificates.
> > >
> > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> > > simon.willi...@thehelpfulcat.com> wrote:
> > >
> > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to
> > > > version 58.0.3029.81.  It appears that this version of Chrome will not
> > > > trust certificates based on Common Name.  Looking at the Chrome
> > > > documentation and borne out by one of the messages, from Chrome 58,
> > > > the subjectAltName is required to identify the DNS name of the host
> > that
> > > > the certificate is issued for.  I would be grateful if someone could
> > point
> > > > me in the direction of how to recreate my SSL certificates so that
> > > > the subjectAltName is populated.
> > > >
> > > > Thanks in advance
> > > >
> > > > --
> > > > Manage your subscription for the Freeipa-users mailing list:
> > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > > Go to http://freeipa.org for more info on the project
> > > >
> > Which version of IPA are you using?
> >
> > The first thing you should do, which I think should be sufficient in
> > most cases, is to tell certmonger to submit a new cert request for
> > each affected certificate, instructing to include the relevant
> > DNSName in the subjectAltName extension in the CSR.
> >
> > To list certmonger tracking requests and look for the HTTPS
> > certificate.  For example:
> >
> > $ getcert list
> > Number of certificate and requests being tracked: 11
> > ...
> > Request ID '20170418012901':
> > status: MONITORING
> > stuck: no
> > key pair storage: type=NSSDB,location='/etc/
> > httpd/alias',nickname='Server-Cert',token='NSS Certificate
> > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > certificate: type=NSSDB,location='/etc/
> > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> > CA: IPA
> > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
> > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
> > expires: 2019-03-22 03:20:19 UTC
> > dns: f25-2.ipa.local
> > key usage: digitalSignature,nonRepudiation,keyEncipherment,
> > dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command:
> > post-save command: /usr/libexec/ipa/certmonger/restart_httpd
> > track: yes
> > auto-renew: yes
> > ...
> >
> > Using the Request ID of the HTTPS certificate, resubmit the request
> > but use the ``-D `` option to specify a DNSName to include
> > in the SAN extension:
> >
> >   $ getcert resubmit -i  -D 
> >
> > ``-D `` can be specified multiple times, if necessary.
> >
> > This should request a new certificate that will have the server DNS
> > name in the SAN extension.
> >
> > HTH,
> > Fraser
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] U2F and ipa for ssh

[Fraser Tweedale]

On Thu, Apr 20, 2017 at 08:04:34AM -0400, Marc Boorshtein wrote:
> Has anyone looked into using U2F with freeipa?  My guess is you would need
> a customized ssh client to interact with the device but in theory you could
> just transform the users U2F public key into an ssh key.
> 
> Marc Boorshtein
> CTO, Tremolo Security, Inc.

Hi Marc,

We have had preliminary discussion about U2F.

As you suggest, U2F requires client support.  U2F does not provide a
general signing operation (it only signs a specific kind of
message[1]) so some server support is probably required as well.

[1] 
https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html#authentication-response-message-success

That said, a lot of U2F devices have additional / alternative modes
with PKCS #11 interfaces, e.g. PIV, allowing them to be used as
generic crypto tokens.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Fraser Tweedale]

On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> I can confirm that I see this behaviour too. My ipa server install is a
> pretty stock install with no 3rd party certificates.
> 
> On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> simon.willi...@thehelpfulcat.com> wrote:
> 
> > Yesterday, Chrome on both my Ubuntu and Windows machines updated to
> > version 58.0.3029.81.  It appears that this version of Chrome will not
> > trust certificates based on Common Name.  Looking at the Chrome
> > documentation and borne out by one of the messages, from Chrome 58,
> > the subjectAltName is required to identify the DNS name of the host that
> > the certificate is issued for.  I would be grateful if someone could point
> > me in the direction of how to recreate my SSL certificates so that
> > the subjectAltName is populated.
> >
> > Thanks in advance
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> >
Which version of IPA are you using?

The first thing you should do, which I think should be sufficient in
most cases, is to tell certmonger to submit a new cert request for
each affected certificate, instructing to include the relevant
DNSName in the subjectAltName extension in the CSR.

To list certmonger tracking requests and look for the HTTPS
certificate.  For example:

$ getcert list
Number of certificate and requests being tracked: 11
...
Request ID '20170418012901':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
expires: 2019-03-22 03:20:19 UTC
dns: f25-2.ipa.local
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: 
post-save command: /usr/libexec/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
...

Using the Request ID of the HTTPS certificate, resubmit the request
but use the ``-D `` option to specify a DNSName to include
in the SAN extension:

  $ getcert resubmit -i  -D 

``-D `` can be specified multiple times, if necessary.

This should request a new certificate that will have the server DNS
name in the SAN extension.

HTH,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] (no subject)

[Fraser Tweedale]

On Thu, Apr 13, 2017 at 04:49:59PM +0200, Tiemen Ruiten wrote:
> Hello!
> 
> As I understand from this
> 
> thread,
> it should be possible to setup a trust between FreeIPA and Samba4. My AD
> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain,
> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to
> one of the FreeIPA replica's and lookup of SRV records in both domains
> appears to work.
> 
> However when I try to add the trust I get "ipa: ERROR an internal error has
> occurred". I ran the trust-add command with full debug logging as described
> on https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust,
> so I can provide these logs privately upon request.
> 
We do not yet support trusts to Samba 4 AD DC.  It is an open
ticket: https://pagure.io/freeipa/issue/4866

I do not think it is a priority at this time.  Alexander (Cc) could
possibly provide an update.

Thanks,
Fraser

> I suspect some DNS-issue, as right after I try to setup the trust, dynamic
> updates stop working on the AD Domain Controller with this error:
> 
> tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor
> code may provide more information, Minor = Server DNS/
> fluorine.clients.i.rdmedia@i.rdmedia.com not found in Kerberos database.
> Failed nsupdate: 1
> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com
> 389
> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com
> 389 (add)
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; UPDATE SECTION:
> _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com. 900 IN SRV 0 100 389
> fluorine.clients.i.rdmedia.com.
> 
> Many thanks in advance for your assistance.
> 
> 
> -- 
> Tiemen Ruiten
> Systems Engineer
> R Media

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates

[Fraser Tweedale]

On Wed, Apr 05, 2017 at 10:38:48PM -0700, Wim Lewis wrote:
> With a bit of tweaking, I was able to generate a usable
> certificate by creating a second host entry,
> 'wildcard.blah.example.com', managed by blah.example.com, and then
> editing the leftmost label from 'wildcard' to '*' in all of the
> host's LDAP entry's properties. 
> 
Suffice to say: this is not a supported or recommended approach :)

> 
> On Apr 3, 2017, at 6:41 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> > The only way is to create a profile that hard-codes the desired SAN
> > data, then use that profile.
> 
> Out of curiosity, if my LDAP approach didn't work, how would I do
> that? I assume it involves `ipa certprofile-import`, but is there
> any documentation on the format it expects? The examples I've
> found have no mention of SANs at all, so it's not clear how I
> would hard code the desired SAN.
> 
Have a look at:
https://www.redhat.com/archives/pki-users/2014-January/msg5.html
Based on the example there you would change a couple of config.

  policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName
  
policyset.serverCertSet.9.default.params.subjAltExtPattern_0=*.blah.exmaple.com

The rest of the profile config could be a direct copy of
caIPAserviceCert, although it would be sensible to remote the
'userExtDefault' component, which is used to copy a SAN extension
from the CSR, would could cause a conflict.

> > Is your instance publicly hosted?  Perhaps the sandstorm.io
> > developers could support ACME/Let's Encrypt so that certs can be
> > automatically acquired for each domain...
> 
> This would be possible, I assume, but it would couple the
> sandstorm instance rather tightly to its CA --- requiring the CA
> to issue a certificate for every new user session. Let's Encrypt
> does rate limiting which would prevent this, for example.
> 
Right.  Let's Encrypt does rate limit per registered domain (max 20
per week according to [1]).  So that would seem to be too low for
your use case.

[1] https://letsencrypt.org/docs/rate-limits/

> An alternative would be to run a local sub-CA for uses like
> sandstorm, but this would require a CA to support issuing
> name-constrained sub-CAs (and if wildcard certs are considered too
> sloppily implemented in real-world clients to be trustworthy, then
> name constraints definitely are!). 
> 
If you trust the IPA CA, you could create a sub-CA under it, export
it, and use it with whatever software can meet your needs.

But this leads me to the question: are you using FreeIPA already and
trying to work out how to fit the Sandstorm use case into it?  Or
are you just looking for a solution for Sandstorm?

> > But see also §7.2 which states that wildcard certs are
> > deprecated :) https://tools.ietf.org/html/rfc6125#section-7.2
> 
> Only mostly deprecated; it admits of legitimate uses for them. :)
> Wildcards are not the best feature of the web PKI, I agree, and I
> wouldn't want to use them if I could think of a viable
> alternative.
> 
The fact that you are looking at FreeIPA suggests that you will be
anchoring your trust at some private CA (not a publicly trusted CA).
If that is the case, then you always have the viable option, "build
the software you need".  It may not exist OOTB but AFAICS there is
nothing fundamentally difficult about your use case.

> (And consider that putting domains in the CN has been deprecated
> since HTTPS/TLS was even a standard, back in 2000 --- yet everyone
> still does that.)
> 
Sure, but do not hold it against us if we follow the standards :)

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] getcert, multiple alternative names (SANs), and wildcard certificates

[Fraser Tweedale]

On Mon, Apr 03, 2017 at 04:17:13PM -0700, Wim Lewis wrote:

> I'm trying to provision a client with a wildcard certificate[1]. I
> followed the procedure outlined in [2], but I'm not receiving the
> certificate I expect. The certificate's subject DN contains a
> wildcard string, but the SAN does not. Since the SAN, not the
> subject name, is the relevant part of the certificate [3], this
> isn't the right certificate.
> 
> What I want is a certificate with two SAN entries, a dNSName for
> "blah.example.com" and another dNSName for "*.blah.example.com".
> But if I request the additional SAN (by passing "-D
> 'blah.example.com' -D '*.blah.example.com'" to getcert) then the
> request fails:
> 
> status: CA_UNREACHABLE
>   ca-error: Server at https://ipa.example.com/ipa/xml failed
>   request, will retry: 4001 (RPC failed at server.  The
>   service principal for subject alt name *.blah.example.com in
>   certificate request does not exist).
> 
> How do I tell FreeIPA that it is OK for it to issue a cert with an
> additional SAN to my host principal?
> 

The only way is to create a profile that hard-codes the desired SAN
data, then use that profile.

The observed behaviour is because FreeIPA's CSR processing checks
that all SAN values present in the CSR actually correspond to the
indicated subject principal(s).  In your case, there is no principal
that has a wildcard in its name, so the cert request gets rejected.

We are not planning to change FreeIPA to support wildcard dnsNames
in SAN.  More commentary below.

> 
> [1] Why am I using a wildcard certificate despite it being easy to
> issue certs from FreeIPA? I'm using it with sandstorm.io, which
> creates a randomly named subdomain for essentially every session.
> This is a reasonable use of wildcard certificates, as I understand
> it, since all of the domains are served from the same process and
> no other domain can match the cert's wildcard - sandstorm owns the
> dns hierarchy under its root.
>
Is your instance publicly hosted?  Perhaps the sandstorm.io
developers could support ACME/Let's Encrypt so that certs can be
automatically acquired for each domain...

> [2] https://www.freeipa.org/page/Howto/Wildcard_certificates
 
> [3] See RFC6125 [B.2], based on RFC 2818, which describes what
> part of the certificate the browser should look at to see if the
> certificate matches the expected hostname. In short, as far as
> HTTPS is concerned, if there are DNS SANs, then the subject field
> of the server's certificate (and its CN) is irrelevant.
>
This is correct.

But see also §7.2 which states that wildcard certs are deprecated :)
https://tools.ietf.org/html/rfc6125#section-7.2

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

[Fraser Tweedale]

Hi Clark,

On Mon, Mar 27, 2017 at 04:19:42PM +, System Administration Team wrote:
> Fraser,
> 
> I cannot pass the DN or CN as part of the subject on the command line 
> ipa-server-install 
> 
> Ipa-server-install appears to set the CN to 'Certificate Authority' from the 
> openssl output.
>
The ability to control this was added in v4.5:
http://www.freeipa.org/page/Releases/4.5.0#Fully_customisable_CA_name

But, the Subject DN in the CSR is advisory; we have no control over
what the external CA actually does.  FreeIPA requires the signed
cert to match what was in the CSR.

> I believe the preferred for a subCA should be the FQDN of the subCA server 
> which is the ipa install.
> 
It doesn't matter, as long as it's different from other CAs.

> The final error when I try to run ipa-server-install:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate 
> not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-install.log for 
> more information
> 
This is consistent with the signed cert having a different Subject
DN from what IPA expects (which is what it put into the CSR).

Cheers,
Fraser

> Thank You
> 
> Clark
> 
> > 
> > 
> Does the subject distinguished name in the signed certificate exactly match 
> what was in the CSR?
> 
> 
> 2017-03-27 IPA Install
> 
> [root@ipa certs]# ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US,mail='
> 
> The log file for this installation can be found in 
> /var/log/ipaserver-install.log 
> ==
> This program will set up the IPA Server.
> 
> This includes:
>   * Configure a stand-alone CA (dogtag) for certificate management
>   * Configure the Network Time Daemon (ntpd)
>   * Create and configure an instance of Directory Server
>   * Create and configure a Kerberos Key Distribution Center (KDC)
>   * Configure Apache (httpd)
> 
> To accept the default shown in brackets, press the Enter key.
> 
> Do you want to configure integrated DNS (BIND)? [no]:
> 
> Certain directory server operations require an administrative user.
> This user is referred to as the Directory Manager and has full access to the 
> Directory for system management tasks and will be added to the instance of 
> directory server created for IPA.
> The password must be at least 8 characters long.
> 
> Directory Manager password:
> Password (confirm):
> 
> The IPA server requires an administrative user, named 'admin'.
> This user is a regular system account used for IPA server administration.
> 
> IPA admin password:
> Password (confirm):
> 
> 
> The IPA Master Server will be configured with:
> Hostname:   ipa.camgian.com
> IP address(es): 192.168.200.3
> Domain name:camgian.com
> Realm name: CAMGIAN.COM
> 
> Continue to configure the system with these values? [no]: yes
> 
> The following operations may take some minutes to complete.
> Please wait until the prompt is returned.
> 
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/47]: creating directory server user
>   [2/47]: creating directory server instance
>   [3/47]: updating configuration in dse.ldif
>   [4/47]: restarting directory server
>   [5/47]: adding default schema
>   [6/47]: enabling memberof plugin
>   [7/47]: enabling winsync plugin
>   [8/47]: configuring replication version plugin
>   [9/47]: enabling IPA enrollment plugin
>   [10/47]: enabling ldapi
>   [11/47]: configuring uniqueness plugin
>   [12/47]: configuring uuid plugin
>   [13/47]: configuring modrdn plugin
>   [14/47]: configuring DNS plugin
>   [15/47]: enabling entryUSN plugin
>   [16/47]: configuring lockout plugin
>   [17/47]: configuring topology plugin
>   [18/47]: creating indices
>   [19/47]: enabling referential integrity plugin
>   [20/47]: configuring certmap.conf
>   [21/47]: configure autobind for root
>   [22/47]: configure new location for managed entries
>   [23/47]: configure dirsrv ccache
>   [24/47]: enabling SASL mapping fallback
>   [25/47]: restarting directory server
>   [26/47]: adding sasl mappings to the directory
>   [27/47]: adding default layout
>   [28/47]: adding delegation layout
>   [29/47]: creating container for managed entries
>   [30/47]: configuring user private groups
>   [31/47]: configuring netgroups from hostgroups
>   [32/47]: creating default Sudo bind user
>   [33/47]: creating default Auto Member layout
>   [34/47]: adding range check plugin
>   [35/47]: creating default HBAC rule allow_all
>   [36/47]: adding sasl mappings to the 

Re: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

[Fraser Tweedale]

On Fri, Mar 24, 2017 at 03:26:31PM +, System Administration Team wrote:
> >From old threads back in August 2016 I have been able to get closer to 
> >installing freeipa server as a subCA to our in house rootCA
> 
> https://www.redhat.com/archives/freeipa-users/2016-August/msg00269.html
> 
> Running the initial install command
> 
> ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US'
> 
> I am provided with /root/ipa.csr that I can signed with our rootCA
> 
> But when I run the subsequent command it fails to find the certificate in the 
> chain.
> 
> ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US' 
> --external-cert-file=/etc/pki/tls/certs/ipasrvr.cert.pem 
> --external-cert-file=/etc/pki/tls/certs/ca.cert.pem
> 
> It fails at:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate 
> not found in /etc/pki/tls/certs/ipasrvr.cert.pem, 
> /etc/pki/tls/certs/ca.cert.pem
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-install.log for 
> more information
> 
> Any help in the correct direction to resolve this will be greatly appreciated.
> 
> Clark
> 
> 
Does the subject distinguished name in the signed certificate
exactly match what was in the CSR?

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA no CA: Which certs are used for LDAPS and web UI?

[Fraser Tweedale]

On Sun, Mar 26, 2017 at 10:52:56PM +, Dagan wrote:
> Hi, 
> 
> I have been asked to look at configuring our new FreeIPA environment using 
> existing externally signed wildcard SSL certificates if possible. 
> 
> I see in the documentation options to specify --dirsrv-cert-file and 
> --http-cert-file with relevant passwords. 
> 
> If we configure these options, are they used as the LDAPS and web UI SSL 
> certificates? 
>
Hi Dagan,

Yes, that is how you specify the LDAP and HTTP certificates.

> If not, are there other command options to specify those as external 
> certificates? 
> 
> Do wildcard certificates cause any problems with FreeIPA? 
> 
Wildcard certs will work fine.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice?

[Fraser Tweedale]

On Wed, Mar 15, 2017 at 06:32:42PM -0400, Chris Dagdigian wrote:
> 
> Any tips for diving into this a bit more to troubleshoot?
> 
> For the 1st time I'm setting up an ipa-server 4.4 replica with CA features
> enabled but the replica install seems to hang forever here:
> 
> ...
> ...
> ...
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
> seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
> 
> < no output after this >
> 
> 
> The replica-install.log file ends here:
> 
> ...
> ...
> ...
> 2017-03-15T22:16:05Z DEBUG Starting external process
> 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active
> pki-tomcatd@pki-tomcat.service
> 2017-03-15T22:16:05Z DEBUG Process finished, return code=0
> 2017-03-15T22:16:05Z DEBUG stdout=active
> 
> 2017-03-15T22:16:05Z DEBUG stderr=
> 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443]
> timeout 300
> 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running
> 2017-03-15T22:16:06Z DEBUG request POST
> http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus
> 2017-03-15T22:16:06Z DEBUG request body ''
> 
> 
> 
> 
> I've confirmed that SELINUX is disabled, there is no firewall and the AWS
> Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance.
> The systemctl command also verifies that
> pki-tomcatd@pki-tomcat.service is "active" as well.
> 
> 
> Any tips for debugging further?
> 
Could you please provide the /var/log/pki/pki-tomcat/ca/debug log
file?

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bad certificate used to sign freeipa

[Fraser Tweedale]

On Fri, Mar 10, 2017 at 01:16:42PM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> I stumbled over this problem:
> 
> http://openbsd-archive.7691.n7.nabble.com/Certificate-Error-quot-format-error-in-certificate-s-notAfter-field-quot-td304262.html
> 
> The details don't really matter. The important point is that
> the root certificate used to sign freeipa's certificate
> appears to be unacceptable on openBSD and maybe others.
> 
> What would you suggest? Is there a guideline to migrate
> freeipa to a new certificate authority?
> 
> 
> Every helpful comment is highly appreciated
> Harri
>
The issue in that thread was resolved.  It was caused by invalid
encoding of the notAfter field.  I think OpenBSD uses LibreSSL in
their base system - and I guess it adheres more strictly to RFC 5280
than other implementations.

As for migrating to a new CA (or merely installing a newer
certificate for the original CA, with correct encoding), you can do
it via ipa-cacert-mangage(1).

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CA not found?

[Fraser Tweedale]

On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote:
> As we're enforcing encryption, here is via ldaps:
> $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager"  -W -s
> sub -b ou=authorities,ou=ca,o=ipaca   Enter LDAP
> Password:
> # extended LDIF
> #
> # LDAPv3
> # base 

Re: [Freeipa-users] CA not found?

[Fraser Tweedale]

On Thu, Feb 09, 2017 at 06:27:12PM -0500, Guillermo Fuentes wrote:
> Hi Fraser,
> 
> The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4
> (CentOS 7) a year ago.
> 
> - Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca':
> SASL/EXTERNAL authentication started
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available:
> 
> - Output providing GSSAPI mechanism:
> $ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure.  Minor code may provide more information (Server
> ldap/localh...@example.com not found in Kerberos database)
> 
> - Output providing user credentials:
> $ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W
> -H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base 

Re: [Freeipa-users] CA not found?

[Fraser Tweedale]

On Thu, Feb 09, 2017 at 09:29:14AM -0500, Guillermo Fuentes wrote:
> Hi list,
> 
> I'm trying to sign a service certificate but it's failing with "CA not found".
> The CA does exist but for some reason the ipa cert-request can't find it:
> $ ipa ca-show ipa
>  Name: ipa
>  Description: IPA CA
>  Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c
>  Subject DN: CN=Certificate Authority,O=EXAMPLE.COM
>  Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM
> 
> This was working in previous versions of freeipa but in our current
> environment isn't working:
> Cluster of four FreeIPA servers
> CentOS Linux release 7.3.1611 (Core)
> ipa-client-common-4.4.0-14.el7.centos.4.noarch
> ipa-client-4.4.0-14.el7.centos.4.x86_64
> ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
> ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64
> ipa-server-4.4.0-14.el7.centos.4.x86_64
> ipa-admintools-4.4.0-14.el7.centos.4.noarch
> ipa-server-common-4.4.0-14.el7.centos.4.noarch
> ipa-common-4.4.0-14.el7.centos.4.noarch
> ipa-server-dns-4.4.0-14.el7.centos.4.noarch
> ipa-python-compat-4.4.0-14.el7.centos.4.noarch
> 389-ds-base-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64
> pki-base-java-10.3.3-16.el7_3.noarch
> pki-base-10.3.3-16.el7_3.noarch
> pki-server-10.3.3-16.el7_3.noarch
> pki-ca-10.3.3-16.el7_3.noarch
> pki-symkey-10.3.3-16.el7_3.x86_64
> pki-kra-10.3.3-16.el7_3.noarch
> pki-tools-10.3.3-16.el7_3.x86_64
> krb5-libs-1.14.1-27.el7_3.x86_64
> python-krbV-1.0.90-8.el7.x86_64
> pam_krb5-2.4.8-6.el7.x86_64
> krb5-workstation-1.14.1-27.el7_3.x86_64
> krb5-pkinit-1.14.1-27.el7_3.x86_64
> sssd-krb5-common-1.14.0-43.el7_3.11.x86_64
> krb5-server-1.14.1-27.el7_3.x86_64
> sssd-krb5-1.14.0-43.el7_3.11.x86_64
> 
> ***
> This is the error (same result in all four servers):
> $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr
> ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not
> found: 0cb513ea-6084-4144-a61c-7a0a8368d25c)
> 
> ***
> >From /var/log/pki/pki-tomcat/ca/debug:
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='xml' value='true'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='profileId' value='caIPAserviceCert'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='authorityId'
> value='0cb513ea-6084-4144-a61c-7a0a8368d25c'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='cert_request' value='(sensitive)'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='cert_request_type' value='pkcs10'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet:
> caProfileSubmitSSLClient start to service.
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> ProfileSubmitServlet: isRenewal false
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to
> ccMode, authorization for servlet: caProfileSubmit is LDAP based, not
> XML {1}, use default authz mgr: {2}.
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> ProfileSubmitServlet: profile: caIPAserviceCert
> CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c
> at 
> com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239)
> at 
> com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128)
> at 
> com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
> at 
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
> at 
> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
> at 
> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
> at 
> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
> at 
> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
>  

Re: [Freeipa-users] Dogtag vs Freeipa Dogtag

[Fraser Tweedale]

On Thu, Feb 02, 2017 at 11:56:55AM +0100, Gorazd wrote:
> Hi Fraser,
> 
> thank you for your comment.
> 
> Still doing some decision making, could anyone know if for example KeyCloak
> (as identity and acces managment solution)+DogTag could have the same or
> better experience (since dogtag has more features than IPA's bundeled
> dogtag) than using Freeipa, what are really the benefits of FreeIPA to use
> it as a system for IdM and PKI solution, is that really just that it has
> integrations with RADIUS also supported, so to be also ready for the deploy
> within typical enterprise environments?
> 
One of the big advantages: if you are issuing certificates for
subject principals defined in the FreeIPA directory, you get a lot
of validation and authorisation for those certificate requests based
on what FreeIPA knows.  It can be quite complicated to set up such a
regime with Dogtag.  OTOH if you need to issue certs for entities
about which FreeIPA knows nothing, then FreeIPA doesn't bring a lot
to the table right now.

If you clearly know what you want but there's isn't support in
FreeIPA, file an RFE.  Like Alexander mentioned there's no guarantee
if or when we can implement it, but at least we will know about it
and be able to work assess it alongside other priorities.

Cheers,
Fraser

> Thank you in advance,
> Gorazd
> 
> 
> 
> On Thu, Feb 2, 2017 at 1:11 AM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> 
> > On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote:
> > > Hello,
> > >
> > > i am interested if there is any feature matrix available for FreeIpa
> > > version of dogtag packaging. So which features of DogTak are not included
> > > or does come with limitations when installed with Freeipa (such as OCSP
> > is
> > > already part of CA and could not be installed seperately), in contrast
> > when
> > > on uses Dogtag as a standlone software installation?
> > >
> > FreeIPA does not use the standalone OCSP responder, or the token
> > processing subsystems (TKS/TPS).  There is nothing preventing you
> > from installing them, but FreeIPA won't help you to do that, and
> > there is no integration.
> >
> > Cheers,
> > Fraser
> >
> > > Thank you in advance.
> > >
> > > Regards,
> > > Gorazd
> >
> > > --
> > > Manage your subscription for the Freeipa-users mailing list:
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > Go to http://freeipa.org for more info on the project
> >
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Dogtag vs Freeipa Dogtag

[Fraser Tweedale]

On Wed, Feb 01, 2017 at 09:44:34PM +0100, Gorazd wrote:
> Hello,
> 
> i am interested if there is any feature matrix available for FreeIpa
> version of dogtag packaging. So which features of DogTak are not included
> or does come with limitations when installed with Freeipa (such as OCSP is
> already part of CA and could not be installed seperately), in contrast when
> on uses Dogtag as a standlone software installation?
> 
FreeIPA does not use the standalone OCSP responder, or the token
processing subsystems (TKS/TPS).  There is nothing preventing you
from installing them, but FreeIPA won't help you to do that, and
there is no integration.

Cheers,
Fraser

> Thank you in advance.
> 
> Regards,
> Gorazd

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] where is ipa cache?

[Fraser Tweedale]

On Sat, Jan 14, 2017 at 07:03:00PM +0800, Matrix wrote:
> Hi, all
> 
> 
> I have removed everything in /var/lib/sss/db. but sudo works fine. 
> 
> 
> I have also tried to capture sudo search packets with tcpdump. I found that 
> there is no packets transferred between ipa client and server. I am wondering 
> where is ipa cache? in memory?
> 
I think it is in memory.  Run `sss-cache -E' to dump the cache.

> 
> Best Regards
> 
> 
> Matrix

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa replica installation help

[Fraser Tweedale]

On Thu, Jan 05, 2017 at 01:08:58PM +0300, Ben .T.George wrote:
> HI
> 
> there is no filrewall running on both servers,
> 
> [root@zkwipamstr01 ~]# systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled;
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:firewalld(1)
> 
> [root@zkwipamstr01 ~]# sestatus
> SELinux status: disabled
> 
OK, very well.  And actually, forget about my idea about connecting
to port 8009 from client - that is not what happens at all.  It is
the end of day for me and my brain checked out :/

I shall continue analysis of your problem tomorrow.

Thanks,
Fraser

> 
> On Thu, Jan 5, 2017 at 1:05 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> 
> > On Thu, Jan 05, 2017 at 12:43:47PM +0300, Ben .T.George wrote:
> > > HI,
> > >
> > > on master server and replica server, i have enabled ipv6
> > >
> > > below on master server
> > >
> > > [root@zkwipamstr01 ~]# ip addr | grep inet6
> > >
> > > inet6 fe80::250:56ff:fea0:3857/64 scope link
> > >
> > > [root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> > > [root@zkwipamstr01 ~]# netstat -tunap | grep 8009
> > > tcp6   0  0 ::1:8009:::*
> > LISTEN
> > >  12692/java
> > >
> > >
> > > after that 8009 is listening on master server.
> > >
> > > on replica side uninstalled ipa and tried to enrolled again. Do i need to
> > > enable any service replica side?
> > >
> > > [28/44]: restarting directory server
> > > ipa : CRITICAL Failed to restart the directory server (Command
> > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> > > exit status 1). See the installation log for details.
> > >   [29/44]: setting up initial replication
> > >   [error] error: [Errno 111] Connection refused
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >
> > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> > > Connection refused
> > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > > ipa-replica-install command failed. See /var/log/ipareplica-install.log
> > for
> > > more information
> > > [root@zkwiparepa01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> > > Job for pki-tomcatd@pki-tomcat.service failed because the control
> > process
> > > exited with error code. See "systemctl status
> > pki-tomcatd@pki-tomcat.service"
> > > and "journalctl -xe" for details.
> > >
> > > Still same error.
> > >
> > > is this service restart pki-tomcatd@pki-tomcat only applicable on master
> > > server?
> > >
> > Yes, because no CA has been created on replica (yet).
> >
> > Can you confirm that your firewall (if any/enabled) on master is
> > letting the traffic from client/replica through to :8009?
> > Executing: ``nc -v $MASTER_IP 8009`` from the client machine
> > suffices to check.
> >
> > Thanks,
> > Fraser
> >
> > > Regards,
> > > Ben
> > >
> > >
> > > On Thu, Jan 5, 2017 at 11:12 AM, Petr Vobornik <pvobo...@redhat.com>
> > wrote:
> > >
> > > > On 01/05/2017 07:10 AM, Ben .T.George wrote:
> > > > > HI
> > > > >
> > > > > yes i did the same and still port is not listening.
> > > > >
> > > > > [root@zkwipamstr01 ~]# cat /etc/hosts
> > > > > 127.0.0.1   localhost localhost.localdomain localhost4
> > > > localhost4.localdomain4
> > > > > ::1 localhost localhost.localdomain localhost6
> > > > localhost6.localdomain6
> > > > > 10.151.4.64 zkwipamstr01.kw.example.com <http://zkwipamstr01.kw.
> > > > example.com>
> > > > > zkwipamstr01
> > > > > 10.151.4.65 zkwiparepa01.kw.example.com <http://zkwiparepa01.kw.
> > > > example.com>
> > > > > zkwiparepa01
> > > > > [root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> > > > > [root@zkwipamstr01 ~]# netstat -tunap | grep 8009
> > > > >
> > > > >
> > > > > Regards
> > > > > Ben
> > > >
> > > > Also IPv6 stack needs to

Re: [Freeipa-users] ipa replica installation help

[Fraser Tweedale]

On Thu, Jan 05, 2017 at 12:43:47PM +0300, Ben .T.George wrote:
> HI,
> 
> on master server and replica server, i have enabled ipv6
> 
> below on master server
> 
> [root@zkwipamstr01 ~]# ip addr | grep inet6
> 
> inet6 fe80::250:56ff:fea0:3857/64 scope link
> 
> [root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> [root@zkwipamstr01 ~]# netstat -tunap | grep 8009
> tcp6   0  0 ::1:8009:::*LISTEN
>  12692/java
> 
> 
> after that 8009 is listening on master server.
> 
> on replica side uninstalled ipa and tried to enrolled again. Do i need to
> enable any service replica side?
> 
> [28/44]: restarting directory server
> ipa : CRITICAL Failed to restart the directory server (Command
> '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> exit status 1). See the installation log for details.
>   [29/44]: setting up initial replication
>   [error] error: [Errno 111] Connection refused
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
> ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> Connection refused
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> ipa-replica-install command failed. See /var/log/ipareplica-install.log for
> more information
> [root@zkwiparepa01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> Job for pki-tomcatd@pki-tomcat.service failed because the control process
> exited with error code. See "systemctl status pki-tomcatd@pki-tomcat.service"
> and "journalctl -xe" for details.
> 
> Still same error.
> 
> is this service restart pki-tomcatd@pki-tomcat only applicable on master
> server?
> 
Yes, because no CA has been created on replica (yet).

Can you confirm that your firewall (if any/enabled) on master is
letting the traffic from client/replica through to :8009?
Executing: ``nc -v $MASTER_IP 8009`` from the client machine
suffices to check.

Thanks,
Fraser

> Regards,
> Ben
> 
> 
> On Thu, Jan 5, 2017 at 11:12 AM, Petr Vobornik <pvobo...@redhat.com> wrote:
> 
> > On 01/05/2017 07:10 AM, Ben .T.George wrote:
> > > HI
> > >
> > > yes i did the same and still port is not listening.
> > >
> > > [root@zkwipamstr01 ~]# cat /etc/hosts
> > > 127.0.0.1   localhost localhost.localdomain localhost4
> > localhost4.localdomain4
> > > ::1 localhost localhost.localdomain localhost6
> > localhost6.localdomain6
> > > 10.151.4.64 zkwipamstr01.kw.example.com <http://zkwipamstr01.kw.
> > example.com>
> > > zkwipamstr01
> > > 10.151.4.65 zkwiparepa01.kw.example.com <http://zkwiparepa01.kw.
> > example.com>
> > > zkwiparepa01
> > > [root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat
> > > [root@zkwipamstr01 ~]# netstat -tunap | grep 8009
> > >
> > >
> > > Regards
> > > Ben
> >
> > Also IPv6 stack needs to be enabled.
> >
> > >
> > > On Thu, Jan 5, 2017 at 9:03 AM, Fraser Tweedale <ftwee...@redhat.com
> > > <mailto:ftwee...@redhat.com>> wrote:
> > >
> > > On Wed, Jan 04, 2017 at 03:12:12PM +0300, Ben .T.George wrote:
> > > > HI
> > > >
> > > > port 8009 is not listening in master server
> > > >
> > > > and i added ::1 localhost localhost.localdomain localhost6
> > > > localhost6.localdomain6 in hosts file.
> > > >
> > >
> > > Did you add this to the host file on the master (then `systemctl
> > > restart pki-tomcatd@pki-tomcat` and confirm it is listening on port
> > > 8009)?  Or just the client you are trying to promote?
> > >
> > > It is needed on the master.  Won't hurt to make this change to
> > > /etc/hosts on both machines, though.
> > >
> > > HTH,
> > > Fraser
> > >
> > >  > still getting same error
> > >  >
> > >  >  [28/44]: restarting directory server
> > >  > ipa : CRITICAL Failed to restart the directory server
> > (Command
> > >  > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
> > non-zero
> > >  > exit status 1). See the installation log for details.
> > >  >   [29/44]: setting up initial replication
> > >  >   [error] error: [Errno 111] Connection refused
> > >  > Your system may be partly configured.
> > >

Re: [Freeipa-users] Replica issue / Certificate Authority

[Fraser Tweedale]

On Wed, Jan 04, 2017 at 01:19:19PM +, Christophe TREFOIS wrote:
> Hi Florence,
> 
> I did what you said, and then the status went to CA_WORKING. Then I restart 
> ipa and certmonger and the status went to CA_UNREACHABLE.
> Then i did “resubmit” again and now the status is back to MONITORING, but the 
> cookie error is back.
> 
> Any advice?
> 
I have encountered the cookie error before. IIRC it was caused by
authn certs in Dogtag user entries not matching the client certs
used.

Check the following entries:

1. ``ldapsearch -LLL -D cn=directory\ manager -w4me2Test \
   -b uid=pkidbuser,ou=people,o=ipaca userCertificate``

   should match

   ``certutil -d /etc/pki/pki-tomcat/alias -L -n "subsystemCert cert-pki-ca"``

2. ``ldapsearch -LLL -D cn=directory\ manager -w4me2Test \
   -b uid=ipara,ou=people,o=ipaca userCertificate``

   should match

   ``certutil -d /etc/httpd/alias -L -n "ipaCert"``

If either of these do not match, update LDAP with what is in the
certificate databases (a.k.a. NSSDBs).  Ensure all certs are
non-expired, etc.

HTH,
Fraser


> [root@lums3 ~]# getcert list -n ipaCert
> Number of certificates and requests being tracked: 8.
> Request ID '20161216025136':
>   status: MONITORING
>   ca-error: Invalid cookie: ''
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-ca-renew-agent
>   issuer: CN=Certificate Authority,O=UNI.LU
>   subject: CN=IPA RA,O=UNI.LU
>   expires: 2018-12-16 03:13:48 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
>   post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
>   track: yes
>   auto-renew: yes
> 
> -- 
> 
> Dr Christophe Trefois, Dipl.-Ing.  
> Technical Specialist / Post-Doc
> 
> UNIVERSITÉ DU LUXEMBOURG
> 
> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
> Campus Belval | House of Biomedicine  
> 6, avenue du Swing 
> L-4367 Belvaux  
> T: +352 46 66 44 6124 
> F: +352 46 66 44 6949  
> http://www.uni.lu/lcsb 
>        
>    
>    
> 
> This message is confidential and may contain privileged information. 
> It is intended for the named recipient only. 
> If you receive it in error please notify me and permanently delete the 
> original message and any copies. 
> 
> 
>   
> 
> > On 4 Jan 2017, at 13:49, Florence Blanc-Renaud  wrote:
> > 
> > getcert resubmit -i 
> 


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa replica installation help

[Fraser Tweedale]

On Wed, Jan 04, 2017 at 03:12:12PM +0300, Ben .T.George wrote:
> HI
> 
> port 8009 is not listening in master server
> 
> and i added ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6 in hosts file.
> 

Did you add this to the host file on the master (then `systemctl
restart pki-tomcatd@pki-tomcat` and confirm it is listening on port
8009)?  Or just the client you are trying to promote?

It is needed on the master.  Won't hurt to make this change to
/etc/hosts on both machines, though.

HTH,
Fraser

> still getting same error
> 
>  [28/44]: restarting directory server
> ipa : CRITICAL Failed to restart the directory server (Command
> '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> exit status 1). See the installation log for details.
>   [29/44]: setting up initial replication
>   [error] error: [Errno 111] Connection refused
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
> ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> Connection refused
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> ipa-replica-install command failed. See /var/log/ipareplica-install.log for
> more information
> 
> 
> Also  ipv6 is disabled on both nodes
> 
> Regards,
> Ben
> 
> On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik  wrote:
> 
> > On 01/04/2017 10:59 AM, Ben .T.George wrote:
> > > HI
> > >
> > > i tried the method mentioned on that document and it end up with below
> > error. My
> > > DNS is managed by external box and i dont want to create any DNS record
> > on these
> > > servers.
> > >
> > > and the command which i tried is(non client server)
> > >
> > > ipa-replica-install --principal admin --admin-password P@ssw0rd --domain
> > > kw.example.com  --server
> > zkwipamstr01.kw.example.com
> > > 
> > >
> > >
> > >
> > > ipa : CRITICAL Failed to restart the directory server (Command
> > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
> > non-zero exit
> > > status 1). See the installation log for details.
> > >[29/44]: setting up initial replication
> > >[error] error: [Errno 111] Connection refused
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >
> > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> > Connection
> > > refused
> > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > > ipa-replica-install command failed. See /var/log/ipareplica-install.log
> > for more
> > > information
> >
> > This looks like bug https://fedorahosted.org/freeipa/ticket/6575
> >
> > To verify that, could you check if master server internally listens on
> > port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
> > near  step 27.
> >
> > Usual fix is to add following line to /etc/hosts
> >   ::1 localhost localhost.localdomain localhost6
> > localhost6.localdomain6
> >
> >
> > > [root@zkwiparepa01 ~]# /bin/systemctl restart
> > dirsrv@KW-EXAMPLE-COM.service
> > > Job for dirsrv@KW-EXAMPLE-COM.service failed because the control
> > process exited
> > > with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service"
> > and
> > > "journalctl -xe" for details.
> > >
> > > [root@zkwiparepa01 ~]# systemctl status dirsrv@KW-EXAMPLE-COM.service
> > > ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server KW-EXAMPLE-COM.
> > > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled;
> > vendor
> > > preset: disabled)
> > > Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46
> > AST; 13s ago
> > >Process: 14893 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i
> > > /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
> > >Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> > > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
> > >   Main PID: 14893 (code=exited, status=1/FAILURE)
> > >
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.177617891 +0300] Error:
> > > betxnpostoperation plu...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.178379752 +0300] Error: object
> > plugin
> > > Roles Pl...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.179162340 +0300] Error:
> > preoperation
> > > plugin su...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.179993432 +0300] Error: object
> > plugin USN
> > > is n...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > 

Re: [Freeipa-users] Replica issue / Certificate Authority

[Fraser Tweedale]

On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:
> Christopher Young wrote:
> > Ok.  I think I have a 'hint' here, but I could use some help getting this 
> > fixed.
> > 
> > Comparing the two IPA servers, I found the following (modified SOME of
> > the output myself):
> 
> You're right about the ipaCert. I'd export the renewed cert from your
> working server using the same certutil command, just direct it to a file
> instead. Then import it into the non-working server and restart the
> httpd service. That should do it.
> 
I agree that this should fix it.

You could also try running `ipa-certupdate' as root, if the correct
certificate is to be found in cn=certificates,cn=ipa,cn=etc,{basedn}

Once everything is working again, you should check:

1. renewal master configuration is correct

2. certmonger tracking requests for the IPA RA cert are correct on
   both servers

3. the correct certificate is in
   cn=certificates,cn=ipa,cn=etc,{basedn}

Thanks,
Fraser

> Or you can try restarting certmonger on the non-working server to see if
>
> that triggers it to pull in the updated cert. Theoretically this should
> do it as well but given potential past replication problems it is
> possible the entry doesn't exist.
> 
> getcert list -n ipaCert on each will show some basic information. The
> important thing is to see if there is some root cause that will make
> this blow up again at renewal time.
> 
> rob
> 
> > 
> > on 'ipa02' (the 'good' one):
> > -
> > ipa cert-show 1
> >   Issuing CA: ipa
> >   Certificate: <<>>
> >   Subject: CN=Certificate Authority,O=.LOCAL
> >   Issuer: CN=Certificate Authority,O=.LOCAL
> >   Not Before: Thu Jan 01 06:23:38 2015 UTC
> >   Not After: Mon Jan 01 06:23:38 2035 UTC
> >   Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
> >   Fingerprint (SHA1):
> > 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
> >   Serial number: 1
> >   Serial number (hex): 0x1
> >   Revoked: False
> > --
> > 
> > 
> > on 'ipa01'
> > -
> > ipa cert-show 1
> > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> > (Invalid Credential.)
> > -
> > 
> > Thinking about this, I decided to just start checking for
> > inconsistencies and I noticed the following:
> > 
> > ipa02:
> > ---
> > [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > openssl x509 -text  | head
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 268304413 (0xffe001d)
> > Signature Algorithm: sha256WithRSAEncryption
> > Issuer: O=x.LOCAL, CN=Certificate Authority
> > Validity
> > Not Before: Nov 23 18:19:31 2016 GMT
> > Not After : Nov 13 18:19:31 2018 GMT
> > Subject: O=x.LOCAL, CN=IPA RA
> > 
> > --
> > ipa01:
> > --
> > [root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > openssl x509 -text  | head
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 7 (0x7)
> > Signature Algorithm: sha256WithRSAEncryption
> > Issuer: O=.LOCAL, CN=Certificate Authority
> > Validity
> > Not Before: Jan  1 06:24:23 2015 GMT
> > Not After : Dec 21 06:24:23 2016 GMT
> > Subject: O=.LOCAL, CN=IPA RA
> > 
> > --
> > 
> > So, it looks like somewhere in the process, the certificate got
> > renewed but not updated on 'ipa01'?  I apologize as I'm trying to
> > understand this.  I believe that my end goal is probably still the
> > same (verify replication and get things working properly on the
> > 'ipa01' system.
> > 
> > Any help is very much appreciated!
> > 
> > -- Chris
> > 
> > 
> > On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young
> >  wrote:
> >> I'm hoping to provide enough information to get some help to a very
> >> important issue that I'm currently having.
> >>
> >> I have two IPA servers at a single location that recently had a
> >> replication issue that I eventually resolved by reinitializing one of
> >> the masters/replicas with one that seemed to be the most 'good'.
> >>
> >> In any case, somewhere in this process, the new IPA 4.4 was release
> >> with/for CentOS 7.3.
> >>
> >> At this moment, regular replication seems to be working properly (in
> >> that I don't have any obvious issues and web interfaces on both
> >> systems seem to be consistent for updates EXCEPT when it comes to the
> >> certificates).
> >>
> >> Before I get to the errors, here is the output of some of the commands
> >> that I would expect anyone would need:
> >>
> >> --
> >> [root@ipa01 ~]# ipa-replica-manage list
> >> ipa01.passur.local: master
> >> ipa02.passur.local: master
> >> -
> >> [root@ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local
> >> ipa02.passur.local: replica
> >>   last init status: None
> >>   last init ended: 1970-01-01 00:00:00+00:00
> >>   last update status: Error (0) Replica 

Re: [Freeipa-users] ipa-server-install fails at DogTag restart

[Fraser Tweedale]

On Wed, Dec 14, 2016 at 05:35:35PM +, Tommy Nikjoo wrote:
> Hi,
> 
> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
> keep getting an error when it tries to restart DogTag
> 
>   [26/31]: restarting certificate server
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
> the Dogtag instance.See the installation log for details.
>   [27/31]: migrating certificate profiles to LDAP
>   [error] NetworkError: cannot connect to
> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
> ipa-server-install command failed. See /var/log/ipaserver-install.log
> for more information
> 
> 
> The log shows the following error
> 
> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
> SSL Server
> 2016-12-14T16:53:05Z DEBUG cert valid True for
> "CN=ldap.example.com,O=EXAMPLE.COM"
> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
> 2016-12-14T16:53:05Z DEBUG response status 200
> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
> 2016 16:53:05 GMT', 'content-type': 'application/xml'}
> 2016-12-14T16:53:05Z DEBUG response body ' encoding="UTF-8" standalone="yes"?> id="ipara">iparaCertificate Manager
> AgentsRegistration Manager Agents'
> 2016-12-14T16:53:05Z DEBUG request POST
> https://ldap.example.com:8443/ca/rest/profiles/raw
> 2016-12-14T16:53:05Z DEBUG request body
> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
> certificates with IECUserRoles extension via IPA-RA agent
> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
> Agent-Authenticated Server Certificate
> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
> Name
> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
> Name
> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
> Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity
> Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key
> Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key
> Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No
> Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority
> Key Identifier
> Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No
> Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA
> Extension
> 

Re: [Freeipa-users] Let's Encrypt along with FreeIPA

[Fraser Tweedale]

On Mon, Dec 05, 2016 at 01:05:46PM -0500, Robert Kudyba wrote:
> 
> >> you seem to have an issue when the LetsEncryptAuthorityX3 is being 
> >> installed. The certificate from the CA that issued this certificate 
> >> (DSTRootCAX3) seems to be installed correctly. Could you verify that 
> >> DSTRootCAX3 is marked as trusted CA by issuing:
> >> 
> >> certutil -d /etc/httpd/alias/ -L
> >> 
> >> The DSTRoootCAX3 should have C,, trust flags.
> >> 
> >> There was an issue fixed last week that might caused this issue if you've 
> >> ever tried to install letsencrypt on this particular VM 
> >> before:https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822
> >>  
> >> 
> >>  If that's the case, you will need to re-install IPA before the 
> >> letsencrypt solution will work.
> 
> I tried to uninstall FreeIPA and Letsencrypt for FreeIPA but I’m getting this:
> 
> ipa-server-install -U --uninstall
> ipa.ipapython.install.cli.uninstall_tool(Server): ERRORServer removal 
> aborted: Deleting this server is not allowed as it would leave your 
> installation without a CA..
> ipa.ipapython.install.cli.uninstall_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for 
> more information
> [root@trill ~]# tail /var/log/ipaserver-uninstall.log
>   File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 
> 270, in decorated
> func(installer)
>   File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 
> 1047, in uninstall_check
> remove_master_from_managed_topology(api, options)
>   File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 
> 310, in remove_master_from_managed_topology
> raise ScriptError(str(e))
> 
> 2016-12-05T17:53:05Z DEBUG The ipa-server-install command failed, exception: 
> ScriptError: Server removal aborted: Deleting this server is not allowed as 
> it would leave your installation without a CA..
> 2016-12-05T17:53:05Z ERROR Server removal aborted: Deleting this server is 
> not allowed as it would leave your installation without a CA..
> 2016-12-05T17:53:05Z ERROR The ipa-server-install command failed. See 
> /var/log/ipaserver-uninstall.log for more information
> 
> Is there a better command?
> 
Try again with the `--ignore-last-of-role' flag.

Cheers,
Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] can(should) IPA issue/manage certificates...

[Fraser Tweedale]

On Thu, Nov 24, 2016 at 04:19:03PM +, lejeczek wrote:
> .. for entities outside of it's own domain?
> Would you use IPA this way?
> 
> I'm thinking - it would be nice that have one central point(console) and
> manage all my "virtual" domains certification, but, I'm not an expert on the
> subject.
> And if yes then what would be the steps?
> 
Can IPA manage certs for "external" entities?  No.

Should it be able to?  Maybe.  There have been some preliminary
discussions about use cases and how it could be implemented.

Do you want to elaborate on your use case?

(Bear in mind that, unless your IPA CA is chained to a publicly
trusted CA, certs issued by it will not be publicly trusted.)

Cheers,
Fraser

> mthx,
> L.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-replica-prepare failing

[Fraser Tweedale]

On Wed, Oct 26, 2016 at 04:18:12PM -0700, Joshua Ruybal wrote:
> While trying to run IPA replica prepare with debug, we see an unexplained
> failure.
> 
> Debug seems to show the process running smoothly, then I see: "Certificate
> issuance failed".
> 
> Looking at previous mail-archives, I see that someone has run into this
> before, however all permissions on caIPAserviceCert.cfg are correct (the
> solution for him).
> 
> Is there any method to get more details on the failure from
> ipa-replica-prepare?
> 
> Thanks
> 
Need some more information to be able to render assistance :)

Do you have any logs pertaining to the failure?  Is certificate
issuance working e.g. via `ipa cert-request'?  Are all certificates
in your infrastructure currently valid?

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Tue, Oct 25, 2016 at 11:02:44AM -0700, Fil Di Noto wrote:
> On Mon, Oct 24, 2016 at 9:55 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> > On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
> >> On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> 
> >> wrote:
> >> > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> >> >> Hello,
> >> >>
> >> >>
> >> >>
> >> >> I would like to better understand why IPA requires SAN (subject 
> >> >> alternative
> >> >> name) entries to have a backing host record. In order to sign a 
> >> >> certificate
> >> >> with a SAN that corresponded to a user friendly CNAME I had to add a 
> >> >> host
> >> >> record (ipa host) for that DNS name (use force option to create without 
> >> >> an
> >> >> A/ record) as well as a service principle.
> >> >>
> >> >>
> >> >>
> >> >> I'm sure I'm not alone when I say I don't like doing that because it 
> >> >> means
> >> >> that a "Host" in FreeIPA is not a computer, it's a host record that may 
> >> >> or
> >> >> may not be the only record that corresponds to a computer. It gets
> >> >> confusing.
> >> >>
> >> >>
> >> >>
> >> >> I assume things are this way to ensure integrity at some level. But I 
> >> >> can't
> >> >> picture it. What is the potential danger of simply bypassing the
> >> >> host/principal checks and just signing the certificate with whatever SAN
> >> >> field we like?
> >> >>
> >> > In this specific case, it is because certmonger requests service
> >> > certificates with host credentials.  Therefore it is not just human
> >> > administrators issuing certs.  And we MUST validate SAN against
> >> > information in the directory (the only "source of truth" available
> >> > to the CA / IPA cert-request command).  Otherwise you could put e.g.
> >> > `google.com' into SAN, and we would issue the cert, and that would
> >> > be Very Bad.
> >> >
> >>
> >> In my case it's always human administrators issuing certs. I can see
> >> how validation is a great way to prevent a scenario like the one you
> >> described. But couldn't that be accommodated by tinkering with the
> >> roles/privileges so that you could impose the restriction on external,
> >> less-trusted applications but allow a trusted human administrator to
> >> bypass it?
> >>
> >> Admin group by default would be nice. It would be unfortunate if
> >> someone added a service account to the admin group, but I don't see
> >> that as justification for ruling it out. How many other poor security
> >> decisions has someone made already before they decided to add a
> >> service account to the domain admin group? To that I would say that
> >> degree of administrative negligence is not something that the project
> >> should design around. But, I don't work at RedHat and I don't have to
> >> take the support calls so my opinion means nothing.
> >>
> >> But if I'm an admin, enforcing the SAN restriction doesn't prevent me
> >> from doing anything I couldn't already do by creating a couple host
> >> records. It's just making things difficult for admins who ultimately
> >> are securely deploying a service.
> >>
> > The question is not really one of privilege, but sanity.  FreeIPA
> > has to make sure that certs issued by it correspond to the CA's view
> > of reality, i.e. what is in the FreeIPA directory, at the time the
> > request is made.  IMO to disable these checks for human users with a
> > particular permission is a mistake waiting to happen.
> >
> > Yes, enforcing the restriction forces a human to put to created the
> > needed objects before the cert request will be considered valid.
> > Not a bad thing, IMO.
> 
> Help me understand. Assuming that the SAN in the CSR are
> valid/intended/non-malicious, can you give me an example scenario
> where sanity becomes a problem? Is IPA going to examine the cert at
> some point in the future and get confused when it doesn't recognize
> the entries in the SAN field?
> 
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Tue, Oct 25, 2016 at 08:01:59AM +0300, Alexander Bokovoy wrote:
> On ti, 25 loka 2016, Fraser Tweedale wrote:
> > On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
> > > On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> 
> > > wrote:
> > > > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> > > >> Hello,
> > > >>
> > > >>
> > > >>
> > > >> I would like to better understand why IPA requires SAN (subject 
> > > >> alternative
> > > >> name) entries to have a backing host record. In order to sign a 
> > > >> certificate
> > > >> with a SAN that corresponded to a user friendly CNAME I had to add a 
> > > >> host
> > > >> record (ipa host) for that DNS name (use force option to create 
> > > >> without an
> > > >> A/ record) as well as a service principle.
> > > >>
> > > >>
> > > >>
> > > >> I'm sure I'm not alone when I say I don't like doing that because it 
> > > >> means
> > > >> that a "Host" in FreeIPA is not a computer, it's a host record that 
> > > >> may or
> > > >> may not be the only record that corresponds to a computer. It gets
> > > >> confusing.
> > > >>
> > > >>
> > > >>
> > > >> I assume things are this way to ensure integrity at some level. But I 
> > > >> can't
> > > >> picture it. What is the potential danger of simply bypassing the
> > > >> host/principal checks and just signing the certificate with whatever 
> > > >> SAN
> > > >> field we like?
> > > >>
> > > > In this specific case, it is because certmonger requests service
> > > > certificates with host credentials.  Therefore it is not just human
> > > > administrators issuing certs.  And we MUST validate SAN against
> > > > information in the directory (the only "source of truth" available
> > > > to the CA / IPA cert-request command).  Otherwise you could put e.g.
> > > > `google.com' into SAN, and we would issue the cert, and that would
> > > > be Very Bad.
> > > >
> > > 
> > > In my case it's always human administrators issuing certs. I can see
> > > how validation is a great way to prevent a scenario like the one you
> > > described. But couldn't that be accommodated by tinkering with the
> > > roles/privileges so that you could impose the restriction on external,
> > > less-trusted applications but allow a trusted human administrator to
> > > bypass it?
> > > 
> > > Admin group by default would be nice. It would be unfortunate if
> > > someone added a service account to the admin group, but I don't see
> > > that as justification for ruling it out. How many other poor security
> > > decisions has someone made already before they decided to add a
> > > service account to the domain admin group? To that I would say that
> > > degree of administrative negligence is not something that the project
> > > should design around. But, I don't work at RedHat and I don't have to
> > > take the support calls so my opinion means nothing.
> > > 
> > > But if I'm an admin, enforcing the SAN restriction doesn't prevent me
> > > from doing anything I couldn't already do by creating a couple host
> > > records. It's just making things difficult for admins who ultimately
> > > are securely deploying a service.
> > > 
> > The question is not really one of privilege, but sanity.  FreeIPA
> > has to make sure that certs issued by it correspond to the CA's view
> > of reality, i.e. what is in the FreeIPA directory, at the time the
> > request is made.  IMO to disable these checks for human users with a
> > particular permission is a mistake waiting to happen.
> > 
> > Yes, enforcing the restriction forces a human to put to created the
> > needed objects before the cert request will be considered valid.
> > Not a bad thing, IMO.
> > 
> > All this said, I think there is a valid RFE in allowing Kerberos
> > principal aliases to be consulted when validating a CSR.  This would
> > mean you do not have to create new objects, just add more principal
> > names to the existing one.  I filed a ticket:
> > 
> > https://fedorahosted.org/freeipa/ticket/6432
> > 
> > Alexander, Simo, w

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
> On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> >> Hello,
> >>
> >>
> >>
> >> I would like to better understand why IPA requires SAN (subject alternative
> >> name) entries to have a backing host record. In order to sign a certificate
> >> with a SAN that corresponded to a user friendly CNAME I had to add a host
> >> record (ipa host) for that DNS name (use force option to create without an
> >> A/ record) as well as a service principle.
> >>
> >>
> >>
> >> I'm sure I'm not alone when I say I don't like doing that because it means
> >> that a "Host" in FreeIPA is not a computer, it's a host record that may or
> >> may not be the only record that corresponds to a computer. It gets
> >> confusing.
> >>
> >>
> >>
> >> I assume things are this way to ensure integrity at some level. But I can't
> >> picture it. What is the potential danger of simply bypassing the
> >> host/principal checks and just signing the certificate with whatever SAN
> >> field we like?
> >>
> > In this specific case, it is because certmonger requests service
> > certificates with host credentials.  Therefore it is not just human
> > administrators issuing certs.  And we MUST validate SAN against
> > information in the directory (the only "source of truth" available
> > to the CA / IPA cert-request command).  Otherwise you could put e.g.
> > `google.com' into SAN, and we would issue the cert, and that would
> > be Very Bad.
> >
> 
> In my case it's always human administrators issuing certs. I can see
> how validation is a great way to prevent a scenario like the one you
> described. But couldn't that be accommodated by tinkering with the
> roles/privileges so that you could impose the restriction on external,
> less-trusted applications but allow a trusted human administrator to
> bypass it?
> 
> Admin group by default would be nice. It would be unfortunate if
> someone added a service account to the admin group, but I don't see
> that as justification for ruling it out. How many other poor security
> decisions has someone made already before they decided to add a
> service account to the domain admin group? To that I would say that
> degree of administrative negligence is not something that the project
> should design around. But, I don't work at RedHat and I don't have to
> take the support calls so my opinion means nothing.
> 
> But if I'm an admin, enforcing the SAN restriction doesn't prevent me
> from doing anything I couldn't already do by creating a couple host
> records. It's just making things difficult for admins who ultimately
> are securely deploying a service.
> 
The question is not really one of privilege, but sanity.  FreeIPA
has to make sure that certs issued by it correspond to the CA's view
of reality, i.e. what is in the FreeIPA directory, at the time the
request is made.  IMO to disable these checks for human users with a
particular permission is a mistake waiting to happen.

Yes, enforcing the restriction forces a human to put to created the
needed objects before the cert request will be considered valid.
Not a bad thing, IMO.

All this said, I think there is a valid RFE in allowing Kerberos
principal aliases to be consulted when validating a CSR.  This would
mean you do not have to create new objects, just add more principal
names to the existing one.  I filed a ticket:

https://fedorahosted.org/freeipa/ticket/6432

Alexander, Simo, what do you think?


> > The problem is slightly exacerbated in that 99% of the time you
> > really want to issue service certs, but FreeIPA does not permit the
> > creation of a service entry without a corresponding host entry.  So
> > you end up with spurious host entries that do not correspond to
> > actual hosts.  I have previously asked about relaxing this
> > restriction.  The idea was rejected (for reasons I don't remember).
> 
> To be fair, I don't think I ever read specifically that a Host in IPA
> was supposed to represent a single computer. But I imagine that the
> majority of people who are using it thought that was the case, at
> least at first. I don't think it would take much abstraction to
> maintain that logical representation for administrators.
> 
> >> If this actually is a necessity and is not likely to change, I think it
> >> would be beneficial to administrators to be able to manage "Hosts" that
> >> correspond to CNAMEs (call them "Alias Hosts&quo

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> Hello,
> 
> 
> 
> I would like to better understand why IPA requires SAN (subject alternative
> name) entries to have a backing host record. In order to sign a certificate
> with a SAN that corresponded to a user friendly CNAME I had to add a host
> record (ipa host) for that DNS name (use force option to create without an
> A/ record) as well as a service principle.
> 
> 
> 
> I'm sure I'm not alone when I say I don't like doing that because it means
> that a "Host" in FreeIPA is not a computer, it's a host record that may or
> may not be the only record that corresponds to a computer. It gets
> confusing.
> 
> 
> 
> I assume things are this way to ensure integrity at some level. But I can't
> picture it. What is the potential danger of simply bypassing the
> host/principal checks and just signing the certificate with whatever SAN
> field we like?
> 
In this specific case, it is because certmonger requests service
certificates with host credentials.  Therefore it is not just human
administrators issuing certs.  And we MUST validate SAN against
information in the directory (the only "source of truth" available
to the CA / IPA cert-request command).  Otherwise you could put e.g.
`google.com' into SAN, and we would issue the cert, and that would
be Very Bad.

The problem is slightly exacerbated in that 99% of the time you
really want to issue service certs, but FreeIPA does not permit the
creation of a service entry without a corresponding host entry.  So
you end up with spurious host entries that do not correspond to
actual hosts.  I have previously asked about relaxing this
restriction.  The idea was rejected (for reasons I don't remember).

> 
> 
> If this actually is a necessity and is not likely to change, I think it
> would be beneficial to administrators to be able to manage "Hosts" that
> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
> are actually enrolled computers. They could be managed in a similar fashion
> to SUDO rules, like maybe:
> 
> 
> 
> Alias Hosts = a single name
> 
> Alias Host Groups = groups of names
> 
> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
> 
> 
> 
> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
> under policy.
>
Now that we have kerberos principal aliases, we might be able to
leverage that, perhaps even directly for service principals.  Any
devs want to chime in on this idea?

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IP SAN in certificates

[Fraser Tweedale]

On Fri, Oct 07, 2016 at 09:30:35AM -0400, Rob Crittenden wrote:
> Alessandro De Maria wrote:
> > Hello,
> > 
> > I am running the following command to create a certificate for etcd
> > 
> > ipa-getcert", "request", "-w", "-r", "-f", "/etc/etcd/ssl/server.crt",
> > "-k", "/etc/etcd/ssl/server.key", "-N", "CN=dock07.prod.zz", "-D",
> > "dock07.prod.", "-A", "10.0.1.67", "-K", "etcd/dock07.prod."
> > 
> > ca-error: Server at https://id1.prod.zz/ipa/xml denied our
> > request, giving up: 2100 (RPC failed at server.  Insufficient
> > access: Subject alt name type IP Address is forbidden).
> > 
> > 
> > 
> > I believe FreeIPA does not currently support IPs as the SAN of a
> > certificate.
> > 
> > Is this still the case? is there a workaroud?
> 
> Still the case (and not likely to change AFAIK) and the only workaround is
> in code.
> 
There have occasionally been discussions about this.  It might be
possible in the future, if we implement an extensible cert request
authorisation mechanism.  Won't happen anytime soon, though.

> rob
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certificate list problems using web ui after upgrading to FreeIPA 4.2.0-15

[Fraser Tweedale]

On Thu, Sep 29, 2016 at 11:13:22PM +0200, Marco Antonio Carcano wrote:
> Hi all,
> 
> I’ve just upgraded from FreeIPA 4.1 to FreeIPA 4.2.0-15 on a CentOS 7
> (7.2.1511) and I’m no more able to list certificates using the web ui
> 
> when I go on “Authentication”,  “Certificates” and chose “Certificates” I
> got the following error
> 
> Certificate operation cannot be completed: Unable to communicate with CMS
> (Internal Server Error)
> 
> and tomcat logs contain the following exception:
> 
> Sep 29, 2016 4:54:35 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Allocate exception for servlet Resteasy
> java.lang.ClassNotFoundException:
> com.netscape.ca.CertificateAuthorityApplication
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:28
> at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:95)
> at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
> at
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
> at
> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
> at 
> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
> at 
> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
> at 
> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
> at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
> at
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:864)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:134)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:40
> at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
> at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> 
> So it complains it cannot find class
> com.netscape.ca.CertificateAuthorityApplication - that’s right
> 
> The funny thing is that command line works like a charm
> 
> pa caacl-find
> 
> 1 CA ACL matched
> 
>   ACL name: hosts_services_caIPAserviceCert
>   Enabled: TRUE
>   Host category: all
>   Service category: all
>   Profiles: caIPAserviceCert
> 
> Number of entries returned 1
> ——
> 
> ipa cert-show
> Serial number: 1
>   Certificate:
> MIIDjzCCAnegAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKEwtJVEM0
> VS5MT0NBTDEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5
> …
> iI2rFqRTA+AF3xpqYBtOP+WwcBaue+OZ/GEsPOiyvcV1ZX6FWcKsmBf/T
> t7A9
>   Subject: CN=Certificate Authority,O=ME.LOCAL
>   Issuer: CN=Certificate Authority,O=ME.LOCAL
>   Not Before: Tue Dec 02 08:05:42 2014 UTC
>   Not After: Sat Dec 02 08:05:42 2034 UTC
>   Fingerprint (MD5): 59:4c:bb:dc:6a:e2:ff:17:6c:34:3e:f4:7e:fa:69:2e
>   Fingerprint (SHA1):
> 74:c1:b3:a1:a1:25:5c:02:e8:ef:c5:30:14:fd:f0:58:79:6d:60:33
>   Serial number (hex): 0x1
>   Serial number: 1
> 
> By the way, the weird thing is that before migrating I added a replica node
> (so a fresh installation of FreeIPA 4.2.0-15) and the replica works
> perfectly, without this problem
> 
> It seems to be a problem somehow 

Re: [Freeipa-users] FreeIPA as CA for your own internal webservices

[Fraser Tweedale]

On Fri, Sep 30, 2016 at 09:17:35AM +0200, Matt . wrote:
> Hi Guys,
> 
> I'm wondering how it's possible to use FreeIPA as your own CA for
> apache vhosts and such.
> 
> I need to many certificates for subdomains (wildcards) that its
> undoable and I would like to use my FreeIAP installs for this.
> 
> I installed the root certificate on windows from my IPA install and
> that works, FreeIPA itself is now trusted. But how to do this for
> other webservices no matter what software I use ?
> 
You'll have to add the IPA CA certificate to all trust stores used
by the programs that talk to services that present a certificate
issued by FreeIPA.  Adding the CA cert to the shared "system" trust
store is sufficient for many programs.  Some programs (including
most browsers) bundle their own trust store or have trusted certs
configured some other way.

If you run into difficult with a specific system or program let us
know and we can try to help :)

Cheers,
Fraser

> I hope someone can give me direction here.
> 
> Thanks!
> 
> Matt
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA Error 4301: CertificateOperationError

[Fraser Tweedale]

On Mon, Aug 22, 2016 at 11:52:46PM +, Z D wrote:
> Hello,
>
> There is the error on ver 4.2 while viewing certs: "IPA Error
> 4301: CertificateOperationError", next it read " Certificate
> operation cannot be completed: Unable to communicate with CMS
> ([Errno 113] No route to host)".
> 
> I suspect you'll be asking for below two commands, here are results.
> 
> # ipa cert-show 1
>   Certificate: 
> MIIDlzCCAn+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1VUy5P
> ..shortened ...
> H6S7tS4pT9w77K8=
>   Subject: CN=Certificate Authority,O=COMP.COM
>   Issuer: CN=Certificate Authority,O=COMP.COM
>   Not Before: Wed Aug 17 17:20:41 2016 UTC
>   Not After: Sun Aug 17 17:20:41 2036 UTC
>   Fingerprint (MD5): 00:a5:2c:2d:ea:c8:27:33:62:35:75:53:12:6a:0d:c1
>   Fingerprint (SHA1): 
> d1:58:78:83:31:b8:ad:ae:af:2c:e7:05:44:67:6e:3a:37:8c:00:1a
>   Serial number (hex): 0x1
>   Serial number: 1
> 
> # ipactl restart
> Restarting Directory Service
> Restarting krb5kdc Service
> Restarting kadmin Service
> Restarting named Service
> Restarting ipa_memcached Service
> Restarting httpd Service
> Restarting ipa-otpd Service
> Restarting ipa-dnskeysyncd Service
> ipa: INFO: The ipactl command was successful
> 
> Any help is appreciated, thanks
> Zarko
>

"while viewing certs" -> do you mean in the IPA Web UI?

The successful `cert-show' command indicates that the CA is up and
running, but the error message indicates that the host running the
failing action cannot contact the CA.  You should check DNS and
firewall settings as a first step.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA vs DogTag CA

[Fraser Tweedale]

On Wed, Aug 17, 2016 at 10:52:53AM +0530, Kaamel Periora wrote:
> Thanks.
> 
> One last question :)
> 
> Will that be feasible to have all the systems (CA, RA, OCSP) on top of
> fedora and upgrade the OS as well as CS with the latest ones time to time.
> This should not affect the exiting data or configuration. With Fedora this
> seems to be a must.
> 
It is feasible, and if you want to stay on supported releases you
will need to do it more frequently on Fedora than on RHEL or CentOS,
because Fedora evolves faster and orphans old releases more eagerly.
Your choice depends on your organisation's technical requirements
and risk appetite ;)

Thanks,
Fraser

> On Tue, Aug 16, 2016 at 5:25 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Tue, Aug 16, 2016 at 04:29:02PM +0530, Kaamel Periora wrote:
> > > Thanks Fraser.
> > >
> > > So basically i can rule out FreeIPA and go ahead with DogTag.
> > >
> > > According to our security requirements, it is not wise to let the genral
> > > public access to the OCSP service running on the CA. I suppose having an
> > > OCSP over Fedora while the others run on CentOS would do.
> > >
> > Sure, you can deploy it that way.  I do not know of anyone who has
> > done so but it should work.
> >
> > > how about RA, can i have it over CentOS?
> > >
> > We no longer have a separate RA subsystem.  RA capabilities are
> > conceptually part of the CA subsystem now.
> >
> > > On Tue, Aug 16, 2016 at 3:04 PM, Fraser Tweedale <ftwee...@redhat.com>
> > > wrote:
> > >
> > > > On Tue, Aug 16, 2016 at 02:54:41PM +0530, Kaamel Periora wrote:
> > > > > Thanks Rob and Fraser, appreciate your time in replying.
> > > > >
> > > > > Currently we are not using FreeIPA but dogtag 9 as an standalone
> > system
> > > > > with RA and OCSP as well.
> > > > >
> > > > > We thought of migrating to the FreeIPA after looking at the the ease
> > of
> > > > > management and excellent support community behind.
> > > > >
> > > > > We require SSL/TLS server certificates and user certificates as well.
> > > > >
> > > > > Currently our major issue is the continuous changes (not stable) in
> > the
> > > > > underlying OS which is Fedora. If we proceed with Dogtag over CentOS
> > or
> > > > > RedHat, will that suffice the stability requirements while
> > delivering the
> > > > > same level of integration with Fedora?
> > > > >
> > > > > your opinion is much appreciated.
> > > > >
> > > > > Kaamel
> > > > >
> > > > FreeIPA and Dogtag are both available in RHEL and CentOS, so you can
> > > > have FreeIPA's ease of management on a less rapidly-evolving
> > > > platform.
> > > >
> > > > Caveat: the standalone OCSP subsystem is not supported on RHEL, but
> > > > the CA subsystem has an inbuilt OCSP responder which may suffice.
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> > > > > On Fri, Aug 12, 2016 at 6:10 AM, Fraser Tweedale <
> > ftwee...@redhat.com>
> > > > > wrote:
> > > > >
> > > > > > On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> > > > > > > Kamal Perera wrote:
> > > > > > > > Dear all,
> > > > > > > >
> > > > > > > > Seeking your kind advices.
> > > > > > > >
> > > > > > > > If the requirement is for having a scalable corporate CA only,
> > is
> > > > it
> > > > > > > > possible to get this requirement fulfilled with DogTag only, or
> > > > install
> > > > > > > > FreeIPA and use the CA functionality only.
> > > > > > >
> > > > > > > IPA limits dogtag to only those features it is interested in.
> > This
> > > > has
> > > > > > been
> > > > > > > expanding recently but you still lose some functionality.
> > > > > > >
> > > > > > > IMHO if all you want is a CA then managing IPA is overkill.
> > > > > > >
> > > > > > > > What are the functional differences and support limitations?
> > > > > > >
> > > > > > > Functionally it depen

Re: [Freeipa-users] FreeIPA vs DogTag CA

[Fraser Tweedale]

On Tue, Aug 16, 2016 at 04:29:02PM +0530, Kaamel Periora wrote:
> Thanks Fraser.
> 
> So basically i can rule out FreeIPA and go ahead with DogTag.
> 
> According to our security requirements, it is not wise to let the genral
> public access to the OCSP service running on the CA. I suppose having an
> OCSP over Fedora while the others run on CentOS would do.
> 
Sure, you can deploy it that way.  I do not know of anyone who has
done so but it should work.

> how about RA, can i have it over CentOS?
> 
We no longer have a separate RA subsystem.  RA capabilities are
conceptually part of the CA subsystem now.

> On Tue, Aug 16, 2016 at 3:04 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Tue, Aug 16, 2016 at 02:54:41PM +0530, Kaamel Periora wrote:
> > > Thanks Rob and Fraser, appreciate your time in replying.
> > >
> > > Currently we are not using FreeIPA but dogtag 9 as an standalone system
> > > with RA and OCSP as well.
> > >
> > > We thought of migrating to the FreeIPA after looking at the the ease of
> > > management and excellent support community behind.
> > >
> > > We require SSL/TLS server certificates and user certificates as well.
> > >
> > > Currently our major issue is the continuous changes (not stable) in the
> > > underlying OS which is Fedora. If we proceed with Dogtag over CentOS or
> > > RedHat, will that suffice the stability requirements while delivering the
> > > same level of integration with Fedora?
> > >
> > > your opinion is much appreciated.
> > >
> > > Kaamel
> > >
> > FreeIPA and Dogtag are both available in RHEL and CentOS, so you can
> > have FreeIPA's ease of management on a less rapidly-evolving
> > platform.
> >
> > Caveat: the standalone OCSP subsystem is not supported on RHEL, but
> > the CA subsystem has an inbuilt OCSP responder which may suffice.
> >
> > Thanks,
> > Fraser
> >
> > > On Fri, Aug 12, 2016 at 6:10 AM, Fraser Tweedale <ftwee...@redhat.com>
> > > wrote:
> > >
> > > > On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> > > > > Kamal Perera wrote:
> > > > > > Dear all,
> > > > > >
> > > > > > Seeking your kind advices.
> > > > > >
> > > > > > If the requirement is for having a scalable corporate CA only, is
> > it
> > > > > > possible to get this requirement fulfilled with DogTag only, or
> > install
> > > > > > FreeIPA and use the CA functionality only.
> > > > >
> > > > > IPA limits dogtag to only those features it is interested in. This
> > has
> > > > been
> > > > > expanding recently but you still lose some functionality.
> > > > >
> > > > > IMHO if all you want is a CA then managing IPA is overkill.
> > > > >
> > > > > > What are the functional differences and support limitations?
> > > > >
> > > > > Functionally it depends on what version of IPA you're talking about.
> > > > Older
> > > > > versions only exposed server certificates. Newer versions support
> > user
> > > > > certifications, custom profiles and more. It is still just a subset
> > of
> > > > what
> > > > > dogtag supports.
> > > > >
> > > > > Support from whom? The dogtag community is happy to help (they've
> > always
> > > > > helped us).
> > > > >
> > > > There are lots of questions that can help you decide which path to
> > > > take: what kinds of certs do you want to issue; to what entities;
> > > > who will issue them; are you already using FreeIPA in your
> > > > organisation?
> > > >
> > > > In regards to functional differences, Dogtag CA and KRA are
> > > > supported with FreeIPA; token processing and standalone OCSP are
> > > > not.  I disagree somewhat with Rob in that unless you need those
> > > > other Dogtag subsystems, I see little disadvantage in using FreeIPA.
> > > > It definitely makes deploying the CA easier and managing renewals
> > > > easier.
> > > >
> > > > The more you tell us of your requirements, the more we can help :)
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA vs DogTag CA

[Fraser Tweedale]

On Tue, Aug 16, 2016 at 02:54:41PM +0530, Kaamel Periora wrote:
> Thanks Rob and Fraser, appreciate your time in replying.
> 
> Currently we are not using FreeIPA but dogtag 9 as an standalone system
> with RA and OCSP as well.
> 
> We thought of migrating to the FreeIPA after looking at the the ease of
> management and excellent support community behind.
> 
> We require SSL/TLS server certificates and user certificates as well.
> 
> Currently our major issue is the continuous changes (not stable) in the
> underlying OS which is Fedora. If we proceed with Dogtag over CentOS or
> RedHat, will that suffice the stability requirements while delivering the
> same level of integration with Fedora?
> 
> your opinion is much appreciated.
> 
> Kaamel
> 
FreeIPA and Dogtag are both available in RHEL and CentOS, so you can
have FreeIPA's ease of management on a less rapidly-evolving
platform.

Caveat: the standalone OCSP subsystem is not supported on RHEL, but
the CA subsystem has an inbuilt OCSP responder which may suffice.

Thanks,
Fraser

> On Fri, Aug 12, 2016 at 6:10 AM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> > > Kamal Perera wrote:
> > > > Dear all,
> > > >
> > > > Seeking your kind advices.
> > > >
> > > > If the requirement is for having a scalable corporate CA only, is it
> > > > possible to get this requirement fulfilled with DogTag only, or install
> > > > FreeIPA and use the CA functionality only.
> > >
> > > IPA limits dogtag to only those features it is interested in. This has
> > been
> > > expanding recently but you still lose some functionality.
> > >
> > > IMHO if all you want is a CA then managing IPA is overkill.
> > >
> > > > What are the functional differences and support limitations?
> > >
> > > Functionally it depends on what version of IPA you're talking about.
> > Older
> > > versions only exposed server certificates. Newer versions support user
> > > certifications, custom profiles and more. It is still just a subset of
> > what
> > > dogtag supports.
> > >
> > > Support from whom? The dogtag community is happy to help (they've always
> > > helped us).
> > >
> > There are lots of questions that can help you decide which path to
> > take: what kinds of certs do you want to issue; to what entities;
> > who will issue them; are you already using FreeIPA in your
> > organisation?
> >
> > In regards to functional differences, Dogtag CA and KRA are
> > supported with FreeIPA; token processing and standalone OCSP are
> > not.  I disagree somewhat with Rob in that unless you need those
> > other Dogtag subsystems, I see little disadvantage in using FreeIPA.
> > It definitely makes deploying the CA easier and managing renewals
> > easier.
> >
> > The more you tell us of your requirements, the more we can help :)
> >
> > Thanks,
> > Fraser
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA vs DogTag CA

[Fraser Tweedale]

On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> Kamal Perera wrote:
> > Dear all,
> > 
> > Seeking your kind advices.
> > 
> > If the requirement is for having a scalable corporate CA only, is it
> > possible to get this requirement fulfilled with DogTag only, or install
> > FreeIPA and use the CA functionality only.
> 
> IPA limits dogtag to only those features it is interested in. This has been
> expanding recently but you still lose some functionality.
> 
> IMHO if all you want is a CA then managing IPA is overkill.
> 
> > What are the functional differences and support limitations?
> 
> Functionally it depends on what version of IPA you're talking about. Older
> versions only exposed server certificates. Newer versions support user
> certifications, custom profiles and more. It is still just a subset of what
> dogtag supports.
> 
> Support from whom? The dogtag community is happy to help (they've always
> helped us).
> 
There are lots of questions that can help you decide which path to
take: what kinds of certs do you want to issue; to what entities;
who will issue them; are you already using FreeIPA in your
organisation?

In regards to functional differences, Dogtag CA and KRA are
supported with FreeIPA; token processing and standalone OCSP are
not.  I disagree somewhat with Rob in that unless you need those
other Dogtag subsystems, I see little disadvantage in using FreeIPA.
It definitely makes deploying the CA easier and managing renewals
easier.

The more you tell us of your requirements, the more we can help :)

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

[Fraser Tweedale]

On Tue, Jul 26, 2016 at 05:16:34AM -0500, Anthony Joseph Messina wrote:
> On Tuesday, July 26, 2016 2:40:38 PM CDT Fraser Tweedale wrote:
> > On Tue, Jul 26, 2016 at 01:45:19PM +1000, Fraser Tweedale wrote:
> > > On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> > > > After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP
> > > > responder" with the following command.  I can confirm certificate with
> > > > serial 0x14 is present in the system and is not expired/revoked, etc. 
> > > > I'm a bit nervous about the "OCSPServlet: Could not locate issuing CA"
> > > > in the Dogtag output below.
> > > > 
> > > > # /usr/bin/openssl ocsp \
> > > > 
> > > >   -issuer /etc/ipa/ca.crt \
> > > >   -nonce \
> > > >   -CAfile /etc/ipa/ca.crt \
> > > >   -url "http://ipa-ca.example.com/ca/ocsp; \
> > > >   -serial 0x14
> > > > 
> > > > # rpm -q freeipa-server pki-server
> > > > freeipa-server-4.3.1-1.fc24.x86_64
> > > > pki-server-10.3.3-1.fc24.noarch
> > > 
> > > Hi Anthony,
> > > 
> > > I wrote this code and I think I know what the issue is.  Could you
> > > please execute `pki-server db-upgrade -v` as root, then try the OCSP
> > > request again?
> > > 
> > > If it works, happy day for you, and for me too because it confirms
> > > the issue which I must fix :)
> > 
> > On further investigation, what I thought was the problem cannot be
> > the problem.  No need to follow my earlier suggestion.
> > 
> > But I found (and fixed) something else.  Would you be willing to try
> > my COPR build[1]?  It contains the linked patch[2] plus whatever is
> > between your installed pki version and the Dogtag master branch at
> > a307cf68e91327ddbef4b9d7e2bbd3991354831f.
> > 
> > [1] https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/build/420751/
> > [2]
> > https://fedorahosted.org/pki/attachment/ticket/2420/pki-ftweedal-0128-Fix-C
> > A-OCSP-responder-when-LWCAs-are-not-in-use.patch
> > 
> > Alternatively, you can apply the patch and build Dogtag yourself
> > (if, e.g., you do not trust my COPR packages, which is fair enough
> > ^_^)
> 
> Your COPR repo with this patch fixes the OCSP responder issue.  Thank you 
> Fraser. -A
> 
Thank you for testing!  Patch will now be reviewed by Dogtag team
and hopefully we can get an official build out soon.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

[Fraser Tweedale]

On Tue, Jul 26, 2016 at 01:45:19PM +1000, Fraser Tweedale wrote:
> On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> > After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP 
> > responder" 
> > with the following command.  I can confirm certificate with serial 0x14 is 
> > present in the system and is not expired/revoked, etc.  I'm a bit nervous 
> > about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output 
> > below.
> > 
> > # /usr/bin/openssl ocsp \
> >   -issuer /etc/ipa/ca.crt \
> >   -nonce \
> >   -CAfile /etc/ipa/ca.crt \
> >   -url "http://ipa-ca.example.com/ca/ocsp; \
> >   -serial 0x14
> > 
> > # rpm -q freeipa-server pki-server
> > freeipa-server-4.3.1-1.fc24.x86_64
> > pki-server-10.3.3-1.fc24.noarch
> > 
> Hi Anthony,
> 
> I wrote this code and I think I know what the issue is.  Could you
> please execute `pki-server db-upgrade -v` as root, then try the OCSP
> request again?
> 
> If it works, happy day for you, and for me too because it confirms
> the issue which I must fix :)
> 
On further investigation, what I thought was the problem cannot be
the problem.  No need to follow my earlier suggestion.

But I found (and fixed) something else.  Would you be willing to try
my COPR build[1]?  It contains the linked patch[2] plus whatever is
between your installed pki version and the Dogtag master branch at
a307cf68e91327ddbef4b9d7e2bbd3991354831f.

[1] https://copr.fedorainfracloud.org/coprs/ftweedal/freeipa/build/420751/
[2] 
https://fedorahosted.org/pki/attachment/ticket/2420/pki-ftweedal-0128-Fix-CA-OCSP-responder-when-LWCAs-are-not-in-use.patch

Alternatively, you can apply the patch and build Dogtag yourself
(if, e.g., you do not trust my COPR packages, which is fair enough
^_^)

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] "Could not locate issuing CA" when querying OCSP responder

[Fraser Tweedale]

On Mon, Jul 25, 2016 at 05:23:31PM -0500, Anthony Joseph Messina wrote:
> After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP 
> responder" 
> with the following command.  I can confirm certificate with serial 0x14 is 
> present in the system and is not expired/revoked, etc.  I'm a bit nervous 
> about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output 
> below.
> 
> # /usr/bin/openssl ocsp \
>   -issuer /etc/ipa/ca.crt \
>   -nonce \
>   -CAfile /etc/ipa/ca.crt \
>   -url "http://ipa-ca.example.com/ca/ocsp; \
>   -serial 0x14
> 
> # rpm -q freeipa-server pki-server
> freeipa-server-4.3.1-1.fc24.x86_64
> pki-server-10.3.3-1.fc24.noarch
> 
Hi Anthony,

I wrote this code and I think I know what the issue is.  Could you
please execute `pki-server db-upgrade -v` as root, then try the OCSP
request again?

If it works, happy day for you, and for me too because it confirms
the issue which I must fix :)

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA doesnt start

[Fraser Tweedale]

On Fri, Jul 01, 2016 at 09:00:03AM +0200, Andreas Ladanyi wrote:
> Hi Fraser.
> >>> Hi,
> >>>
> >>> i upgraded from Fedora 22 to 23 and now iam working with IPA 4.2
> >>>
> >>> When i want to start IPA with ipactl start i run into the situation
> >>> starting pki-tomcat take a long time and ipactl aborts the starting
> >>> process and shutdown services. So IPA doesnt start.
> >> Sounds like 
> >> https://www.happyassassin.net/2016/06/21/notes-on-a-couple-of-freeipa-bugs-host-group-sudo-rules-and-failure-to-start-with-recent-pki-core-on-older-upgraded-installs/
> >>
> > I concur - it is likely to be the same issue.  A new release of pki
> > on f23 is going to happen in the next day or so.  If it is the same
> > issue, that will fix it.
> yes it was the same issue. I could fix it.
> 
> Andreas
> 
Glad to hear it, Andreas.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA doesnt start

[Fraser Tweedale]

On Thu, Jun 30, 2016 at 03:36:22PM +0200, Tomasz Torcz wrote:
> On Thu, Jun 30, 2016 at 02:51:02PM +0200, Andreas Ladanyi wrote:
> > Hi,
> > 
> > i upgraded from Fedora 22 to 23 and now iam working with IPA 4.2
> > 
> > When i want to start IPA with ipactl start i run into the situation
> > starting pki-tomcat take a long time and ipactl aborts the starting
> > process and shutdown services. So IPA doesnt start.
> 
> Sounds like 
> https://www.happyassassin.net/2016/06/21/notes-on-a-couple-of-freeipa-bugs-host-group-sudo-rules-and-failure-to-start-with-recent-pki-core-on-older-upgraded-installs/
> 
I concur - it is likely to be the same issue.  A new release of pki
on f23 is going to happen in the next day or so.  If it is the same
issue, that will fix it.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Fraser Tweedale]

On Thu, Jun 02, 2016 at 05:35:01PM -0400, bret.wort...@damascusgrp.com wrote:
> Sorry, let me back up a step. We need to implement hype
> everywhere. All our web services. And clients need to get
> keys automatically whether through IPA or Puppet. These
> systems use IPA for everything but authentication (to keep most
> users off). I'm trying to wuss out the easiest way to make this
> happen smoothly.
> 
Hi Bret,

You can use the IPA CA to sign service certificates.  See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store.  If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser

> 
> 
> On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden, wrote:
> > Bret Wortman wrote:
> > > Is it possible to use our freeipa CA as a trusted CA to sign our
> > > internal SSL certificates? Our system runs on a private network and so
> > > using the usual trusted sources isn't an option. We've been using
> > > self-signed, but that adds some additional complications and we thought
> > > this might be a good solution.
> > > 
> > > Is it possible, and, since most online guides defer to "submit the CSR
> > > to Verisign" or whomever, how would you go about producing one in this 
> > > way?
> > 
> > Not sure I understand the question. The IPA CA is also self-signed. For
> > enrolled systems though at least the CA is pre-distributed so maybe that
> > will help.
> > 
> > rob
> > 

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates

[Fraser Tweedale]

On Thu, May 26, 2016 at 12:08:11PM +0200, Youenn PIOLET wrote:
> Hi there,
> 
> For your information :
> I just realised today that the certificate signing using web interface was
> still broken.
> 
> I've got 3 caIPAserviceCert.cfg files on my system :
> 
> Locate  caIPAserviceCert.cfg output
> 1. New profile :  /usr/share/ipa/profiles/caIPAserviceCert.cfg
> 2. Old broken profile : /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg
> 3. Old broken profile :
> /var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg
> LDAP profile version was not OK, back to the older version of profile. I
> fixed it back.
> 
> FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem
> > which stores profile configuration in LDAP.
> >
> 
> I think my Dogtag (in IPA web interface) was still using the files (and
> replacing the LDAP entry after a while? Or did it happen when a added a new
> replica?).
> 
Yes - installing a new replica will re-clobber the profile
configuration.

Patches to fix the problem are merged upstream and will make their
way into an upcoming bugfix release.

Thanks,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] freeipa as organizational CA

[Fraser Tweedale]

On Wed, May 11, 2016 at 12:06:39PM +, Andy Thompson wrote:
> > Andy, you can install FreeIPA as a sub-CA of your offline root.
> > Support for creating sub-CAs *within* FreeIPA, under the "main"
> > FreeIPA CA (which in your case is a sub-CA of your offline root), is not yet
> > available but I am working on that.  But if you only need one CA as a sub-CA
> > of an offline root, you can use FreeIPA today.
> > 
> 
> I've got this setup and working with an openssl minted root CA, I've minted a 
> few certs and it all seems to work well enough.  I'm trying to sort out what 
> features I might be missing using the FreeIPA implementation in this setup as 
> compared to setting up dogtag, ejbca or looking at the RHCS product.
> 
> I've tried accessing the dogtag web console and it doesn't work on the IPA 
> server.
> 
The full Dogtag web UI is available on port 8443.

If you features like token processing or dedicated OCSP instance,
these are only officially supported as part of RHCS.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates

[Fraser Tweedale]

; > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=
> > > https://ipa.example.com/ipa/crl/MasterCRL.bin
> > > 100,109d97
> > > < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl
> > > < policyset.serverCertSet.10.constraint.name=No Constraint
> > > <
> > >
> > policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl
> > > < policyset.serverCertSet.10.default.name=Subject Key Identifier
> > Extension
> > > Default
> > > < policyset.serverCertSet.10.default.params.critical=false
> > > < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl
> > > < policyset.serverCertSet.11.constraint.name=No Constraint
> > > < policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl
> > > < policyset.serverCertSet.11.default.name=User Supplied Extension
> > Default
> > > < policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
> > >
> > > Thanks by advance for your support,
> > > Regards
> > >
> > > --
> > > Youenn Piolet
> > > piole...@gmail.com
> > >
> > >
> > > 2016-03-31 9:41 GMT+02:00 Fraser Tweedale <ftwee...@redhat.com>:
> > >
> > > > On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote:
> > > > > Hello,
> > > > >
> > > > > I seem to be having some issues with IPA CA feature not generating
> > > > > certificates with DNS SubjectAltNames.
> > > > >
> > > > > I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now
> > under
> > > > > CentOS 7.2 / IPA 4.2 something's different.
> > > > >
> > > > > Here are the original steps which worked fine for my first use case
> > ::
> > > > >
> > > > > $ ipa dnsrecord-add example.com mail --a-ip=172.17.100.25
> > > > > $ ipa host-add mail.example.com
> > > > > $ ipa service-add smtp/mail.example.com
> > > > > $ ipa service-add smtp/mail1.example.com
> > > > > $ ipa service-add-host smtp/mail.example.com --hosts=
> > mail1.example.com
> > > > > $ ipa-getcert request -k /etc/pki/tls/private/postfix.key \
> > > > >   -f /etc/pki/tls/certs/postfix.pem   \
> > > > >   -N CN=mail1.example.com,O=EXAMPLE.COM \
> > > > >   -D mail1.example.com -D mail.example.com \
> > > > >   -K smtp/mail1.example.com
> > > > > (and repeat for every next member of the cluster...)
> > > > >
> > > > > After this, I would get certificate with something like ::
> > > > > $ sudo ipa-getcert list
> > > > > Number of certificates and requests being tracked: 3.
> > > > > Request ID '20150419153933':
> > > > >   status: MONITORING
> > > > >   stuck: no
> > > > >   key pair storage:
> > > > > type=FILE,location='/etc/pki/tls/private/postfix.key'
> > > > >   certificate:
> > type=FILE,location='/etc/pki/tls/certs/postfix.pem'
> > > > >   CA: IPA
> > > > >   issuer: CN=Certificate Authority,O=EXAMPLE.COM
> > > > >   subject: CN=mail1.example.com,O=EXAMPLE.COM
> > > > >   expires: 2017-04-19 15:39:35 UTC
> > > > >   dns: mail1.example.com,mail.example.com
> > > > >   principal name: smtp/mail1.example@example.com
> > > > >   key usage:
> > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > > > >   eku: id-kp-serverAuth,id-kp-clientAuth
> > > > >   pre-save command:
> > > > >   post-save command:
> > > > >   track: yes
> > > > >   auto-renew: yes
> > > > >
> > > > > with Subject line in form of: 'CN=,O=EXAMPLE.COM' and
> > 'dns'
> > > > > info line present.
> > > > >
> > > > > Suddenly, in the current setup, after upgrade from 4.0 to 4.2, I'm
> > > > > getting this ::
> > > > >
> > > > > $ ipa dnsrecord-add example.com w3 --a-ip=172.17.17.80 --a-create-
> > > > > reverse
> > > > > $ ipa host-add w3.example.com
> > > > > $ ipa service-add HTTP/w3.example.com
> > > > > $ ipa service-add HTTP/http1.example.com
> &g

Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates

[Fraser Tweedale]

On Tue, May 10, 2016 at 11:51:26AM +0200, Youenn PIOLET wrote:
> Hi Fraser, Martin,
> 
> I've got exactly the same problem with no DNS AltName and OU=pki-ipa,O=IPA
> in the subject.
> 
Hi Youenn,

I'm currently investigating this issue; the state of the system
is clear but I'm still trying to work out how it gets there.

Could you confirm whether you are on RHEL / CentOS 7.2, and if so,
whether it was installed at 7.2 or an upgrade from 7.1 or an earlier
version?

Further commentary below.

> ### certprofile
> $ ipa certprofile-show --out caIPAserviceCert.cfg caIPAserviceCert
> ---
> Profile configuration stored in file 'caIPAserviceCert.cfg'
> ---
>   Profile ID: caIPAserviceCert
>   Profile description: Standard profile for network services
>   Store issued certificates: TRUE
> 
You do not include the caIPAserviceCert.cfg in the diffs below,
however, I suspect you will find it to be identical to
/usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg.  Could you
please confirm this?

> 
> ### My /etc/pki/pki-tomcat/ca/CS.cfg :
> http://pastebin.com/wnVWH8bq
> 
Thanks for sharing; everything looks fine here.

> ### caIPAserviceCert
> I'd like to send you my caIPAserviceCert.cfg, two of them are present on my
> system:
> 
> - /usr/share/ipa/profiles/caIPAserviceCert.cfg :
> http://pastebin.com/byddqgSF
>
(The rest of my reply is just an FYI on where FreeIPA/Dogtag stores
profile configurtion.)

Profile configurations in /usr/share/ipa/profiles/ are templates
owned by IPA, with placeholders that get filled out when IPA imports
the profile.

> - /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg :
> http://pastebin.com/FFUTytDq
> 
Profiles stored here are the default profiles added to a Dogtag
instance, however, the files at these locations are not used by
running instances.

But wait, there's more!  You should also find
/var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg.  This
one is used by Dogtag if the file-based ProfileSubsystem is used.

FreeIPA since v4.2 configures Dogtag to use the LDAPProfileSubsystem
which stores profile configuration in LDAP.  The file output by the
``ipa certprofile-show`` command will have come from LDAP; this is
the version that's actually in use in your IPA installation.

Cheers,
Fraser


> And a diff between them :
> 
> $ diff /usr/share/ipa/profiles/caIPAserviceCert.cfg
> /usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg
> 1,2d0
> < profileId=caIPAserviceCert
> < classId=caEnrollImpl
> 15c13
> < policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11
> ---
> > policyset.serverCertSet.list=1,2,3,4,5,6,7,8
> 22c20
> < policyset.serverCertSet.1.default.params.name=CN=$$
> request.req_subject_name.cn$$, $SUBJECT_DN_O
> ---
> > policyset.serverCertSet.1.default.params.name=CN=$
> request.req_subject_name.cn$, OU=pki-ipa, O=IPA
> 48c46
> <
> policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://
> $IPA_CA_RECORD.$DOMAIN/ca/ocsp
> ---
> > policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=
> 95,97c93,95
> <
> policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER
> <
> policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName
> < policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://
> $IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin
> ---
> > policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=
> > policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=
> > policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=
> https://ipa.example.com/ipa/crl/MasterCRL.bin
> 100,109d97
> < policyset.serverCertSet.10.constraint.class_id=noConstraintImpl
> < policyset.serverCertSet.10.constraint.name=No Constraint
> <
> policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl
> < policyset.serverCertSet.10.default.name=Subject Key Identifier Extension
> Default
> < policyset.serverCertSet.10.default.params.critical=false
> < policyset.serverCertSet.11.constraint.class_id=noConstraintImpl
> < policyset.serverCertSet.11.constraint.name=No Constraint
> < policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl
> < policyset.serverCertSet.11.default.name=User Supplied Extension Default
> < policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
> 
> Thanks by advance for your support,
> Regards
> 
> --
> Youenn Piolet
> piole...@gmail.com
> 
> 
> 2016-03-31 9:41 GMT+02:00 Fraser Tweedale <ftwee...@redhat.com>:
> 
> > On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefan

Re: [Freeipa-users] freeipa as organizational CA

[Fraser Tweedale]

On Mon, May 09, 2016 at 10:23:07PM +0300, Alexander Bokovoy wrote:
> On Mon, 09 May 2016, Andy Thompson wrote:
> >Is freeipa in RHEL7.2 able to be used as an organizational CA these
> >days?  I have a requirement to set one up and like the IPA interface
> >and tools, but can't sort out the current state in 4.2 to decipher
> >whether this is possible, or even reasonable to try.  I need to setup
> >an org sub CA with an offline root CA
> Sub-CA support is coming in FreeIPA 4.4, hopefully. Current code in RHEL
> 7.2 does not support sub-CA functionality.
> 
Andy, you can install FreeIPA as a sub-CA of your offline root.
Support for creating sub-CAs *within* FreeIPA, under the "main"
FreeIPA CA (which in your case is a sub-CA of your offline root), is
not yet available but I am working on that.  But if you only need
one CA as a sub-CA of an offline root, you can use FreeIPA today.

> >The dogtag pki-ca in 7.2 appears to be missing some pieces, none of the
> >management themes seem to be available and the console utilities are
> >hit and miss, so I'm looking at this possibility.  Seems like overkill
> >but thought I'd toss the idea around.
> I think RHCS is a separate product with support on top of RHEL 7. Check
> with your Red Hat representatives.
> -- 
> / Alexander Bokovoy
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Duplicate serials in issued ipa certs

[Fraser Tweedale]

On Fri, May 06, 2016 at 11:33:10AM +, wouter.hummel...@kpn.com wrote:
> Hello,
> 
> I discovered today that our IPA CA has been issuing certs with duplicate 
> serials, causing issues in several ways when dealing with hosts that have 
> such a cert in place. (Complaints about duplicate serials)
> Removing the offending cert from the host results in de same type of error
> These all seem to have been issued from the server that in the past was 
> reinstalled with the same hostname.
> 
Can you please describe the history of the server in more detail?
(i.e. what do you mean by "was reinstalled" - including whether it
was a replica, etc).  Also, which FreeIPA version(s) are you using?

Thanks,
Fraser

> ipa host-show app
> ipa: ERROR: Certificate format error: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) 
> You are attempting to import a cert with the same issuer/serial as an 
> existing cert, but that is not the same cert.
> 
> IPA cert-find indeed shows 2 issued certs with the same serial (several 
> actually)
> 
> (anonymized)
> Serial number (hex): 0xFFF0007
>   Serial number: 268369927
>   Status: VALID
>   Subject: CN=app.example.org,O=EXAMPLE.ORG
> 
>   Serial number (hex): 0xFFF0007
>   Serial number: 268369927
>   Status: VALID
>   Subject: CN=ipa.example.org,O=EXAMPLE.ORG
> 
> The ipa client won't let me revoke or otherwise kill these certs with the 
> same error.
> What to do?
> 
> Met vriendelijke groet,
> 
> Wouter Hummelink
> Cloud Engineer
> [Description: Beschrijving: Beschrijving: cid:image003.gif@01CC7CE9.FCFEC140]
> KPN IT Solutions
> Platform Organisation Cloud Services
> Mail: wouter.hummel...@kpn.com
> Telefoon: +31 (0)6 1288 2447
> [cid:image002.png@01D0DA65.706AE4B0]
> P Save Paper - Do you really need to print this e-mail?
> *
> KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, 
> Handelsregister 52959597 Amsterdam
> The information transmitted is intended only for use by the addressee and may 
> contain confidential and/or privileged material.
> Any review, re-transmission, dissemination or other use of it, or the taking 
> of any action in reliance upon this information by persons
> and/or entities other than the intended recipient is prohibited. If you 
> received this in error, please inform the sender and/or addressee immediately
> and delete the material. Thank you.
> *
> 




> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Dogtag migration to FreeIPA

[Fraser Tweedale]

On Thu, May 05, 2016 at 12:46:48PM -0700, Ha T. Lam wrote:
> Hi Fraser,
> 
> Thank you very much for the immediate response. Our use-case for Dogtag is:
> our installation engineers request a signing CA cert through the Dogtag web
> interface, and our admin grants the request, anything following is not
> managed with Dogtag. So we only use Dogtag for managing the root cert and
> the signing CA certs (beside OCSP, audit certs, etc that come with the
> system).
> 
> I'm not sure how your solution would work in our case, if we import a
> signing cert into Dogtag and sign other certs that we give to our
> installation engineers using it, it would change our current cert chain.
> 
> Reading your reply, I realized I probably misunderstood how FreeIPA worked,
> I thought I only needed to import Dogtag's Root CA (which is our company
> Root CA) into FreeIPA's Dogtag for it to work. Just for checking, this
> would not work, would it?
> 
Correct; there isn't right now a way to "adopt" an existing CA into
an existing Dogtag instance.

In either case, because you are issuing admin-approved CA
certificates, I don't think FreeIPA fits your use case.  In the
future we will support sub-CA creation (it is what I am working on)
so you might want to evaluate FreeIPA once that feature has landed.

Cheers,
Fraser

> Thanks,
> Ha
> 
> On Wed, May 4, 2016 at 7:24 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> 
> > On Wed, May 04, 2016 at 06:51:20PM -0700, Ha T. Lam wrote:
> > > Hi,
> > >
> > > We have an in-house CA system managed by a stand-alone Dogtag system, we
> > > would like to integrate it with our FreeIPA system which is already in
> > use
> > > and is setup with the company LDAP. I'm new to FreeIPA and I have some
> > > questions about this process:
> > >
> > > 1. Is it possible to add our current Dogtag on top of the FreeIPA system
> > > directly? If so, how would I achieve that?
> > >
> > This is not supported, though it's technically feasible (we just
> > don't have any code to do it).
> >
> > > 2. If it's not possible to do the above, what about setting up a clone of
> > > the current FreeIPA system and migrate Dogtag during the installation of
> > > the replica? Is this a better option?
> > >
> > Same as above... technically feasible but no way to do it right now.
> >
> > > 3. Any other alternative?
> > >
> > One alternative is to export your CA signing cert and key, and
> > install a new Dogtag instance in your FreeIPA environment.  The IPA
> > Dogtag instance would be "detached" from your existing Dogtag
> > instance but, cryptographically speaking, it would be the same CA.
> >
> > You would have to tweak serial number ranges to ensure the new
> > instance doesn't reuse serial numbers that were already used (a
> > simple procedure).
> >
> > How well this would work in your organisation would depend on what
> > sorts of things you use the exiting Dogtag for, how clients expect
> > to renew certificates, etc.  I'm happy to answer questions you might
> > have in considering this approach.
> >
> > Cheers,
> > Fraser
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Dogtag migration to FreeIPA

[Fraser Tweedale]

On Wed, May 04, 2016 at 06:51:20PM -0700, Ha T. Lam wrote:
> Hi,
> 
> We have an in-house CA system managed by a stand-alone Dogtag system, we
> would like to integrate it with our FreeIPA system which is already in use
> and is setup with the company LDAP. I'm new to FreeIPA and I have some
> questions about this process:
> 
> 1. Is it possible to add our current Dogtag on top of the FreeIPA system
> directly? If so, how would I achieve that?
> 
This is not supported, though it's technically feasible (we just
don't have any code to do it).

> 2. If it's not possible to do the above, what about setting up a clone of
> the current FreeIPA system and migrate Dogtag during the installation of
> the replica? Is this a better option?
> 
Same as above... technically feasible but no way to do it right now.

> 3. Any other alternative?
> 
One alternative is to export your CA signing cert and key, and
install a new Dogtag instance in your FreeIPA environment.  The IPA
Dogtag instance would be "detached" from your existing Dogtag
instance but, cryptographically speaking, it would be the same CA.

You would have to tweak serial number ranges to ensure the new
instance doesn't reuse serial numbers that were already used (a
simple procedure).

How well this would work in your organisation would depend on what
sorts of things you use the exiting Dogtag for, how clients expect
to renew certificates, etc.  I'm happy to answer questions you might
have in considering this approach.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Lost master 1 with CA service

[Fraser Tweedale]

On Wed, May 04, 2016 at 08:45:19PM +0800, barry...@gmail.com wrote:
> Hi all:
> 
> I got master 1have ca and server 2 replicatiomng . Now master 1
> fail all lost.
> 
> Can i skip.it just make server 3 repliacted slaved or must
> recovered master 1.
> 
I take it `Server 2' was installed without the CA?  If this is the
case, and if you cannot recover the first master with the CA
instance, then as long as you still have the replica info file with
which the replica(s) were created, then you have the bits to recover
the CA - but it will be quite an involved process.

I have never performed this recovery so there is no documentation,
but off the top of my head the steps would be (at a high level; no
detail yet):

1. Make some manual changes to make FreeIPA think it is CA-less

2. Extract CA signing key from the replica info file

3. Run ipa-ca-install to install the CA on one of the IPA servers,
   with external CA.  This will generate a new private key and CSR
   to send to external CA.

4. Replace the new private key generated for the CSR, with the
   private key from the replica info file.

5. Continue the ipa-ca-install with the CA signing certificate from
   the replica info file.

6. Manually adjust serial number ranges to ensure the new CA
   instance does not issue certs with serial numbers that collide
   with certs issued by the original CA instance.  (This might have
   to be hacked into the ipa-ca-install process).

7? Depending on whether your CA is self-signed, might need to tell
   certmonger to track the CA signing certificate.

8! Install a CA replica on another IPA server, so you don't have to
   do it all again if you lose the CA host in future :)

If you want to embark on this adventure, and get stuck (I know my
instructures were not detailed...), let me know.  I will try and
find spare minutes to learn the details and document the process.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] change CA subject or "friendly name"?

[Fraser Tweedale]

On Mon, Apr 11, 2016 at 11:43:17AM -0400, Anthony Clark wrote:
> Hello All,
> 
> I'm in the process of deploying FreeIPA 4 in a development environment.
> One of my testers has imported the ca.pem file into Windows, and indicates
> that it displays as:
> 
> Issued to: Certificate Authority
> Issued by: Certificate Authority
> Friendly Name: 
> 
> This will unfortunately cause confusion among certain end users, so I was
> wondering if there's a way to change those attributes?
> 
> Ideally without reinstalling everything, but thankfully we're still early
> in the process so it's OK if do blow everything away.
> 
> Do I need to generate a new CA outside of FreeIPA and then use
> ipa-cacert-manage to "renew" the base CA?
> 
> Thanks,
> 
> Anthony Clark

Hi Anthony,

After a brief investigation it appears that ``Friendly Name'' is a
property that can be set in a Windows certificate store, and is not
part of, or derived from, the certificate itself.

Here are a couple of TechNet articles that might help:

- https://technet.microsoft.com/en-us/library/cc740218%28v=ws.10%29.aspx
- 
https://blogs.technet.microsoft.com/pki/2008/12/12/defining-the-friendly-name-certificate-property/

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] certutil - how to delete an orphan key..

[Fraser Tweedale]

On Fri, Apr 08, 2016 at 03:39:49PM -0400, Rob Crittenden wrote:
> Pawel Eljasz wrote:
> >.. would anybody know?
> >I realize this might be not the ideal place for such a question, sorry.
> >thanks
> >L
> >
> >
> 
> I don't know that there is a way using a tool to delete a key from an NSS
> database. Why do you want to? It won't hurt anything.
> 
> rob
> 
According to man page, to list contents of key database:

certutil ... -K

and to delete a particular key:

certutil ... -F -n $KEY_ID

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Announcing FreeIPA 4.3.1

[Fraser Tweedale]

On Fri, Apr 08, 2016 at 10:33:32AM +0200, Martin Kosek wrote:
> On 03/24/2016 10:23 PM, Petr Vobornik wrote:
> > The FreeIPA team would like to announce FreeIPA v4.3.1 bug fixing release!
> > 
> > It can be downloaded from http://www.freeipa.org/page/Downloads. The builds 
> > are
> > available for Fedora 24 and rawhide. Builds for Fedora 23 are available in 
> > the
> > official COPR
> > repository.
> > Experimental builds for CentOS 7 will be available in the official FreeIPA
> > CentOS7 COPR
> > repository
> > shortly after Easter Holidays.
> > 
> > This announcement with links to Trac tickets is available on
> > http://www.freeipa.org/page/Releases/4.3.1 .
> > 
> > Fedora 24 update: 
> > https://bodhi.fedoraproject.org/updates/freeipa-4.3.1-1.fc24
> 
> For the record, I just finished upgrading FreeIPA Public Demo to version 
> 4.3.1.
> Besides other improvements noted on the release page, the good news is that 
> the
> FreeIPA demo web server now scores "A" in the SSL Labs SSL Server Test (the
> cipher update is done automatically after upgrade to 4.3.1).
> 
Nice!  Kudos to Christian for the cipher suite upgrade.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Install/promote new CA old one corrupted before backups

[Fraser Tweedale]

On Fri, Apr 01, 2016 at 08:24:44AM -0500, McNiel, Craig wrote:
> Sadly -
> 
> I don't think that CA is installed on other replica's  They were installed
> following the replica-prepare and replica-install process with nothing else
> done outside of this process to install CA.
> 
> I did not have backups yet when the incident occurred so I only have the
> replica's created from the original CA/master
> 
> The documentation that I was following was the following
> 
> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
> 
> I rapidly ran into issues with this on the replica's which I suspect is due
> to them not having CA installed.
> 
Correct; the "promote CA to renewal master" means promoting an
existing CA replica to be the default replica for certificate
renewal and CRL generation.

Have you kept any of the *replica files* with with the replicas were
created.  The replica file is what is produced by the
`ipa-replica-prepare' command, and is supplied to
`ipa-replica-install' to actually install the replica.  From any one
of these files you can extract the CA signing certificate and run
`ipa-ca-install' on one of the replicas to reinstate the CA.

I have never attempted this but some of the gotchas might be:

- some manual updates in IPA directory might be necessary to "trick"
  it into believe it is a hitherto CA-less deployment

- some config changes may be needed to ensure the new CA instance
  issues certificates starting from an appropriate serial number
  (how many certs were previously issued by the now-lost CA?)

If you can confirm that you do have a replica file I will spend the
time to work out exactly what you need to do.

Cheers,
Fraser


> Thanks !
> 
> Craig
> 
> On Fri, Apr 1, 2016 at 2:15 AM, Martin Basti  wrote:
> 
> >
> >
> > On 31.03.2016 16:09, McNiel, Craig wrote:
> >
> > I was installing a 7 host IPA with ipa01 being the CA and the others being
> > replicas of this node.  This was to be the production installation of IPA
> > and the admins/users started using it prior to the installation being
> > completed and before I had snapshots/backup created of the servers.
> >
> > The ipa01 host disk was corrupted so I no longer have a CA just the other
> > 6 nodes.  How can I install/promote or otherwise recreate the CA?  I have
> > looked online for instructions but, I run into issues almost immediately
> > with the accuracy for the version I'm using in the documenation as many of
> > the files it indicates need updates don't even exist.
> >
> > Thanks
> >
> > ipa-python-4.2.0-15.el7.centos.3.x86_64
> > ipa-admintools-4.2.0-15.el7.centos.3.x86_64
> > ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
> > sssd-ipa-1.13.0-40.el7_2.1.x86_64
> > ipa-server-4.2.0-15.el7.centos.3.x86_64
> > libipa_hbac-1.13.0-40.el7_2.1.x86_64
> > ipa-client-4.2.0-15.el7.centos.3.x86_64
> >
> >
> >
> >
> >
> > Hello,
> >
> > Several things are not clear to me from you email. Can you please answer
> > following questions?
> >
> > Do you have CA installed on other replicas?
> > Do you have backup of the original server (ipa-backup, or snapshot)?
> > Which documentation did you follow?
> > What did you try?
> >
> > Martin Basti
> >
> 
> 
> 
> -- 
> 
> *Craig McNiel*
> 
> Assessment and Instruction
> 
> 2510 North Dodge Street
> Iowa City, Iowa 52240
> 
> D: 319-341-6390
> C: 319-430-9252
> T: 877-627- (Team On-call Support)
> 
> Pearson
> Always Learning
> Learn more at www.pearsonassessments.com

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates - private files

[Fraser Tweedale]

On Thu, Mar 31, 2016 at 09:49:20AM +0200, Martin Štefany wrote:
> Hello Fraser,
> 
> here are the files for real, thank you for help.
> 
> Martin
>
Thanks Martin,

So what appears to have happened is somehow the default profile
`caIPAserviceCert`, which is shipped with Dogtag, was imported into
LDAP instead of the version shipped with IPA.  I do not know how
this might have occurred - it will help to know the history of your
installation e.g. was it a fresh install, upgrade from a Centos/RHEL
7.1, migration (ipa-replica-install) of an earlier version, etc.

In any case, how to resolve?  You can import a corrected version of
the profile.  I have attached an example config, but you should
check it to make sure it is what you want; in particular check the
following values:


policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, 
O=EXAMPLE.COM


policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp


policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin


policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate
 Authority,o=ipaca

You can update the profile with the new profile data by executing:

ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg

Hopefully this fixes the issue.

A fallback suggestion: if the above command fails, and if `ipa
certprofile-find` shows no objects, then you may be able to resolve
the issue by setting, in `/etc/pki/pki-tomcat/ca/CS.cfg`:

subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem

and then running `ipa-server-upgrade` manually.

I am on PTO tomorrow but look forward to learning on Monday how you
fared.  Others may be able to help in the meantime.

Cheers,
Fraser
profileId=caIPAserviceCert
classId=caEnrollImpl
desc=This certificate profile is for enrolling server certificates with IPA-RA 
agent authentication.
visible=false
enable=true
enableBy=admin
auth.instance_id=raCertAuth
name=IPA-RA Agent-Authenticated Server Certificate Enrollment
input.list=i1,i2
input.i1.class_id=certReqInputImpl
input.i2.class_id=submitterInfoInputImpl
output.list=o1
output.o1.class_id=certOutputImpl
policyset.list=serverCertSet
policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, 
O=EXAMPLE.COM
policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=731
policyset.serverCertSet.2.default.params.startTime=0
policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl
policyset.serverCertSet.3.constraint.name=Key Constraint
policyset.serverCertSet.3.constraint.params.keyType=RSA
policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096
policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl
policyset.serverCertSet.3.default.name=Key Default
policyset.serverCertSet.4.constraint.class_id=noConstraintImpl
policyset.serverCertSet.4.constraint.name=No Constraint
policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl
policyset.serverCertSet.4.default.name=Authority Key Identifier Default
policyset.serverCertSet.5.constraint.class_id=noConstraintImpl
policyset.serverCertSet.5.constraint.name=No Constraint
policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl
policyset.serverCertSet.5.default.name=AIA Extension Default
policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true
policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName
policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp
policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1
policyset.serverCertSet.5.default.params.authInfoAccessCritical=false
policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1
policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint
policyset.serverCertSet.6.constraint.params.keyUsageCritical=true

Re: [Freeipa-users] DNS SubjectAltName missing in provisioned certificates

[Fraser Tweedale]

On Sun, Mar 27, 2016 at 09:14:47PM +0200, Martin Štefany wrote:
> Hello,
> 
> I seem to be having some issues with IPA CA feature not generating
> certificates with DNS SubjectAltNames.
> 
> I'm sure this worked very well under CentOS 7.1 / IPA 4.0, but now under
> CentOS 7.2 / IPA 4.2 something's different.
> 
> Here are the original steps which worked fine for my first use case ::
> 
> $ ipa dnsrecord-add example.com mail --a-ip=172.17.100.25
> $ ipa host-add mail.example.com
> $ ipa service-add smtp/mail.example.com
> $ ipa service-add smtp/mail1.example.com
> $ ipa service-add-host smtp/mail.example.com --hosts=mail1.example.com
> $ ipa-getcert request -k /etc/pki/tls/private/postfix.key \
>                       -f /etc/pki/tls/certs/postfix.pem   \
>                       -N CN=mail1.example.com,O=EXAMPLE.COM \
>                       -D mail1.example.com -D mail.example.com \
>                       -K smtp/mail1.example.com
> (and repeat for every next member of the cluster...)
> 
> After this, I would get certificate with something like ::
> $ sudo ipa-getcert list
> Number of certificates and requests being tracked: 3.
> Request ID '20150419153933':
>   status: MONITORING
>   stuck: no
>   key pair storage:
> type=FILE,location='/etc/pki/tls/private/postfix.key'
>   certificate: type=FILE,location='/etc/pki/tls/certs/postfix.pem'
>   CA: IPA
>   issuer: CN=Certificate Authority,O=EXAMPLE.COM
>   subject: CN=mail1.example.com,O=EXAMPLE.COM
>   expires: 2017-04-19 15:39:35 UTC
>   dns: mail1.example.com,mail.example.com
>   principal name: smtp/mail1.example@example.com
>   key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: 
>   post-save command: 
>   track: yes
>   auto-renew: yes
> 
> with Subject line in form of: 'CN=,O=EXAMPLE.COM' and 'dns'
> info line present.
> 
> Suddenly, in the current setup, after upgrade from 4.0 to 4.2, I'm
> getting this ::
> 
> $ ipa dnsrecord-add example.com w3 --a-ip=172.17.17.80 --a-create-
> reverse
> $ ipa host-add w3.example.com
> $ ipa service-add HTTP/w3.example.com
> $ ipa service-add HTTP/http1.example.com
> $ ipa service-add-host HTTP/w3.example.com --hosts=http1.example.com
> $ ipa-getcert request -k /etc/pki/tls/private/httpd.key \
>                       -f /etc/pki/tls/certs/httpd.pem   \
>                       -N CN=http1.example.com,O=EXAMPLE.COM \
>                       -D http1.example.com -D w3.example.com \
>                       -K HTTP/http1.example.com
> $ sudo ipa-getcert list
> Number of certificates and requests being tracked: 3.
> Request ID '20160327095125':
>   status: MONITORING
>   stuck: no
>   key pair storage:
> type=FILE,location='/etc/pki/tls/private/http.key'
>   certificate: type=FILE,location='/etc/pki/tls/certs/http.pem'
>   CA: IPA
>   issuer: CN=Certificate Authority,O=EXAMPLE.COM
>   subject: CN=http1.example.com,OU=pki-ipa,O=IPA
>   expires: 2018-03-28 09:51:27 UTC
>   key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: 
>   post-save command: 
>   track: yes
>   auto-renew: yes
> 
> Where's the 'CN=,OU=pki-ipa,O=IPA' coming from instead of
> 'CN=,O=EXAMPLE.COM' and why are DNS SubjectAltNames missing?
> 
> To be clear, if I don't do ::
> $ ipa service-add-host HTTP/w3.example.com --hosts=http1.example.com
> 
> then certificate is just not issued with 'REJECTED', but once this is
> done properly in described steps, DNS SANs are not happening.
> 
> I've tried ipa-getcert from both CentOS 7.2 and Fedora 23, but only
> against my current IPA 4.2 on CentOS 7.2.
> 
> For the actual certificates ::
> $ sudo openssl x509 -in /etc/pki/tls/certs/postfix.pem -noout -text
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 15 (0xf)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: O=EXAMPLE.COM, CN=Certificate Authority
> Validity
> Not Before: Apr 19 15:39:35 2015 GMT
> Not After : Apr 19 15:39:35 2017 GMT
> Subject: O=EXAMPLE.COM, CN=mail1.example.com
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
>                     [cut]
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Authority Key Identifier: 
> keyid:[cut]
> 
> Authority Information Access: 
> OCSP - URI:http://ipa-ca.example.com/ca/ocsp
> 
> X509v3 Key Usage: critical
> Digital Signature, Non Repudiation, Key Encipherment,
> Data Encipherment
> X509v3 Extended Key Usage: 
> TLS Web Server Authentication, TLS Web Client
> Authentication
> 

Re: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape

[Fraser Tweedale]

On Mon, Mar 28, 2016 at 10:55:06AM -0500, Endi Sukma Dewata wrote:
> On 3/28/2016 10:00 AM, Rob Crittenden wrote:
> >Timothy Geier wrote:
> >>>Thanks for the procedure..the good news is this worked quite
> >>>well in making sure that 389 didn’t crash immediately after
> >>>startup.  The bad news is that the certificates still didn’t
> >>>renew due to
> >>>
> >>>Server at "http://master_server:8080/ca/ee/ca/profileSubmit
> >>>"
> >>>
> >>>replied: Profile caServerCert Not Found
> >>>
> >>>which was the same error in getcert list I saw that one time
> >>>389 didn’t crash right away.  At least now this can be further
> >>>troubleshooted without worrying about 389.
> >>>
> >>>
> >>
> >>To follow up on this issue, we haven’t been able to get any
> >>further since last month due to the missing caServerCert
> >>profile..the configuration files
> >>/usr/share/pki/ca/profiles/ca/caServerCert.cfg and
> >>/var/lib/pki/pki-tomcat/ca/profiles/ca/caServerCert.cfg are
> >>present and are identical.   The pki-ca package passes rpm -V as
> >>well.   Are there any other troubleshooting steps we can take?
> >
> >Maybe Endi or Ade have some ideas why the CA isn't recognizing
> >the profile.
> >
> >rob
> >
> 
> Fraser, is it possible the profile is missing from LDAP?
> 
There is a ticket for a situation where migration of profiles to
LDAP does not occur:
https://bugzilla.redhat.com/show_bug.cgi?id=1300252

See also upstream ticket:
https://fedorahosted.org/freeipa/ticket/5682

The fix is awaiting release for RHEL.

A possible workaround is to modify
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg, replacing the value:

com.netscape.cmscore.profile.LDAPProfileSubsystem

with:

com.netscape.cmscore.profile.ProfileSubsystem

Then running `ipa-server-upgrade`.  The upgrade program should
observe that LDAP-based profiles are not enabled, re-enable the
LDAPProfileSubsystem and import all file-based profiles into the
database.

If you are able to try this procedure, let me know how it goes.

Cheers,
Fraser

> Timothy, could you provide us with the CA debug logs
> (/var/log/pki/pki-tomcat/ca/debug) and CA configuration file
> (/var/lib/pki/pki-tomcat/ca/conf/CS.cfg)?
> 
> Thanks!
> 
> -- 
> Endi S. Dewata

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Wed, Mar 23, 2016 at 04:37:43PM +1100, a.fed...@earsdown.com
wrote:
> Some excellent points, and thank you for being open to having the
> conversation - I know you don't have to, and it is appreciated.
> 
> > Profiles which are allowed for a host principal (representing
> > physical or virtual machines) are not necessarily the same
> > profiles that should be used for service principals.  This is
> > why CA ACLs must be executed against the issuee principal.
> 
> 
> Certmonger uses the host credential (from the host keytab) to make
> all requests on behalf of all service principals of a given
> machine, right?
>
That's correct.

> So if that machine is compromised then so too are
> all keys/certificates issued to that machine. If I think a machine
> is more likely to become compromised, I'd want to lock down the
> Certificate Profiles available to that whole machine.
>
Protecting keys is a separate issue from the the CA being able to
answer the question "can I issue certs to principal P using profile
X?".

> Even if I
> end up using different profiles for different services on the same
> machine, I'm still forced to trust certmonger to use the right
> profile for each request.
> 
CA ACLs are stored and evaluated on the IPA server.  If Certmonger
uses the "wrong profile for a request", the worst that will happen
is CA ACL enforcement will deny the request.  I do not see how any
special trust resides in Certmonger in this scenario.

> So, even with future sub-CAs (this excites me btw), I'm just not
> sure I understand the security benefit of evaluating CA ACLs
> against the subject/issuee of the request, when (as you say)
> directory ACIs are already doing this.
> 
Directory ACIs govern which principals can request a certificate on
behalf of a subject principal.  CA ACLs govern which profile(s) are
valid for such a request.  These are quite different things, and
both are important.

(I'm glad you're excited about sub-CA support; I am too!)

> Lets look at this from another angle. Suppose I obtain a service
> keytab for my unprivileged web application (say
> HTTP/myapp01.example.com), which is needed to authenticate web
> clients via kerberos/gssapi. The app also needs x509 certificates
> for TLS, which is handled by certmonger. Given the current
> approach of CA ACLs, it would be possible for my unprivileged
> web-app (if it were to become compromised) to use its service
> keytab to request certificates from IPA directly, which is
> undesirable, but I'd have no way of stopping it.
> 
The same is true for rogue user or host credentials.  The scope is
even bigger for compromised host credentials, since a host principal
can request certificates both for itself and for any services it
manages.

> I'm even more curious about how I'd explain and justify this
> behaviour to clients. It's confusing, you know?
> 
I am open to any ideas about how to explain this more clearly.  The
best approach I can think of is to explain that CA ACLs are about
answering, "what kinds of certificate can the CA issue to subject
principal 'P'?", and emphasising that that is a very different
question from, "who can request a certificate on behalf of subject
principal 'P'?".

Thanks,
Fraser

> Cheers
> 
> > On 23 Mar 2016, at 09:48, Fraser Tweedale <ftwee...@redhat.com>
> > wrote:
> > 
> >> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote: Hi
> >> Fraser, Martin and Alexander,
> >> 
> >> Thanks for looking into this! For what it's worth, I think for
> >> this particular use case, I'm leaning more towards Alexander
> >> when he said:
> >> 
> >>> I don't think you need to group services this way. For
> >>> managing services, and this means being able to issue
> >>> certificates/keytabs for them, we have hosts. By default a
> >>> host that a service belongs to is capable to modify
> >>> userCertificate attribute of the service already, so I would
> >>> expect it to be able to issue certificates with subject
> >>> principal corresponding to the service.
> >> 
> >>> If CAACL would follow the same logic by allowing hosts that
> >>> manage services to issue certificates with subject principals
> >>> corresponding to these services, that should be enough
> >>> because, after all, these host objects already have write
> >>> permissions and can upload whatever certificates they like to
> >>> the service objects.  -- / Alexander Bokovoy
> >> 
> >> Personally, I was very surprised when I discovered that, even
> >> though a host principal may manage a service principal, it is
> >&g

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Tue, Mar 22, 2016 at 09:59:58AM +0100, Martin Kosek wrote:
> On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> > On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
> ...
> > To my fellow FreeIPA developers: are service groups a sensible RFE?
> > Is there a reason why they have not been implemented?
> 
> It *is* sensible RFE and it was actually already filed!
> 
> https://fedorahosted.org/freeipa/ticket/5277
> 
> Please feel free to add yourself to CC to receive updates or even help us with
> implementation.
> 
> Thanks,
> Martin
>
Good to know... I've added myself to Cc and also filed an RFE for
enhancing CA ACLs with service groups once #5277 is implemented:
https://fedorahosted.org/freeipa/ticket/5753

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] User certificate workflow

[Fraser Tweedale]

On Tue, Mar 15, 2016 at 09:39:12AM +, Alessandro De Maria wrote:
> Thank you Martin that's very helpful.
> 
> The annoying thing about cut/paste from web ui is that the cert is not
> wrapped at 60 chars like it should be, but I guess I'll have to wait for
> the save certificate functionality.
> Any idea of then that's planned for?
> 
> Regards
> Alessandro
> 
Hi Alessandro,

The easiest way to get the cert is with the `ipa user-show` (if
it was saved to the IPA direct after issuance, which is controlled
by the `store` option Martin mentioned). E.g.:

ipa user-show alice --out=cert.pem

Which will save alice's certificate(s) to the file `cert.pem`.

If you copy the data from the web UI and save it to a file, the
following will convert it to PEM:

base64 -d < cert.txt | openssl x509 -inform DER > cert.pem

Finally, to configure a profile to issue certificates with a
validity of X days, the relevant profile configuration is:

policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=X
policyset.serverCertSet.2.default.params.startTime=0

Replace `X` above with the desired lifetime in days.  (Note that the
index (`2`, above) may be different for different profiles.)

Cheers,
Fraser

> On 15 March 2016 at 08:50, Martin Babinsky <mbabi...@redhat.com> wrote:
> 
> > On 03/15/2016 08:39 AM, Alessandro De Maria wrote:
> >
> >> Hello,
> >>
> >> I would like to have authenticated users to upload a csr request and
> >> have their certificate automatically signed. Their certificate would
> >> expire in x days.
> >>
> >> Given the short life of the certificate, I would then like them to be
> >> able to easily download the certificate.
> >>
> >> Any suggestion on how to do it?
> >> I would prefer the shell script approach but also having it self
> >> serviced on the web ui would be great.
> >>
> >> Regards
> >>
> >>
> >> --
> >> Alessandro De Maria
> >> alessandro.dema...@gmail.com <mailto:alessandro.dema...@gmail.com>
> >>
> >>
> >>
> > Hi Alessandro,
> >
> > for FreeIPA 4.2+ you can use the following links as a guide to set up a
> > custom profile and CA ACL rules so that users can request certificates for
> > themselves:
> >
> > http://www.freeipa.org/page/V4/User_Certificates#How_to_Test
> >
> > https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/
> >
> > The user then can generate CSR request e.g. using OpenSSL and use 'ipa
> > cert-request' to send it to IPA CA. If you specify 'store=True' when adding
> > the custom certificate profile, the certificate will be added to the user
> > entry as 'usercertificate;binary' attribute which he can view from
> > CLI/WebUI as PEM and save it to a file by copy-pasting it (The
> > functionality to save the certificate directly to a file is under
> > development).
> >
> > It should be possible to modify the certificate profile to restrict the
> > maximum validity of the issued certificate but I have no knowledge about
> > that. I have CC'ed Fraser Tweedale (the blog post author), he may help you
> > with this.
> >
> > --
> > Martin^3 Babinsky
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> >
> 
> 
> 
> -- 
> Alessandro De Maria
> alessandro.dema...@gmail.com

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing?

[Fraser Tweedale]

On Mon, Feb 22, 2016 at 06:42:04PM +0100, Natxo Asenjo wrote:
> On Sat, Feb 20, 2016 at 5:58 PM, Ian Pilcher  wrote:
> 
> > I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a
> > traceback every time pki-cad starts:
> >
> > Traceback (most recent call last):
> >   File "/usr/sbin/pki-server", line 89, in 
> > cli.execute(sys.argv)
> >   File "/usr/sbin/pki-server", line 84, in execute
> > super(PKIServerCLI, self).execute(args)
> >   File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute
> > module.execute(module_args)
> >   File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line
> > 103, in execute
> > scriptlet.execute()
> >   File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py",
> > line 50, in execute
> > cert = self.subsystem.get_system_cert('subsystem')
> >   File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93,
> > in get_system_cert
> > cert['request'] = base64.b64decode(self.config['%s.%s.certreq' %
> > (self.prefix, tag)])
> > KeyError: 'ca.subsystem.certreq'
> > Starting pki-ca:   [  OK  ]
> >
> > As you can see, the daemon does still start successfully, and the
> > traceback doesn't appear in any of the pki-cad logs.
> >
> >
> yes, I see this too after the last round of updates. Curiously enough, just
> on one of the kdcs, the other does not have this traceback.
> 
> Both are centos 6.7 fully patched, 32 bits.
> 
You can resolve the issue by stopping pki-cad, adding
'ca.subsystem.certreq=' (empty value) to CS.cfg, then restarting
pki-cad.  AFAICT the absense of the certreq field will not cause any
problems.

I'm still investigating what caused the 'ca.subsystem.certreq'
config to disappear from CS.cfg in the first place.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] nss unrecognized name alert with SAN name

[Fraser Tweedale]

On Sun, Feb 07, 2016 at 12:05:19PM +0100, John Obaterspok wrote:
> 2016-02-06 23:29 GMT+01:00 Rob Crittenden :
> 
> > John Obaterspok wrote:
> >
> >> Hi,
> >>
> >> I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan
> >>
> >> I recently started to get nss error "SSL peer has no certificate for the
> >> requested DNS name." when I'm accesing my https://gitserver.my.lan
> >>
> >> Previously this worked fine if I had set "git config --global
> >> http.sslVerify false" according to
> >> https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html
> >>
> >> Now I tried to solve this by adding a SubjectAltName to the
> >> HTTP/ipa.my.lan certitficate like this:
> >>
> >> status: MONITORING
> >> stuck: no
> >> key pair storage:
> >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> >> certificate:
> >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> >> Certificate DB'
> >> CA: IPA
> >> issuer: CN=Certificate Authority,O=MY.LAN
> >> subject: CN=ipa.my.lan,O=MY.LAN
> >> expires: 2018-02-06 19:24:52 UTC
> >> dns: gitserver.my.lan,ipa.my.lan
> >> principal name: http/ipa.my@my.lan
> >> key usage:
> >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> >> eku: id-kp-serverAuth,id-kp-clientAuth
> >> pre-save command:
> >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> >> track: yes
> >> auto-renew: yes
> >>
> >> But I still get the below error:
> >>
> >> * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT)
> >> * SSL peer has no certificate for the requested DNS name
> >>
> >
> > What version of mod_nss? It recently added support for SNI. You can try
> > turning it off by adding NSSSNI off to /etc/httpd/conf.d/nss.conf but I'd
> > imagine you were already relying on it.
> >
> >
> Hi,
> 
> Turning it off didn't help
> 
> I'm on F23 with latest updates so I have mod_nss-1.0.12-1
> I noticed it worked if I set "ServerName gitserver.my.lan" in
> gitserver.conf, but then I got the NAME ALERT when accessing ipa.my.lan.
> 
> I then tried to put ipa.conf in  but then I got error
> about SSL_ERROR_RX_RECORD_TOO_LONG
> 
> gitserver.conf has this:
> 
> 
> DocumentRoot /opt/wwwgit
> SetEnv GIT_PROJECT_ROOT /opt/wwwgit
> SetEnv GIT_HTTP_EXPORT_ALL
> SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
> ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
> 
> ServerName gitserver.my.lan
> 
>   
>   Options Indexes
>   AllowOverride None
>   Require all granted
>  
> 
>  
>   Options Indexes
>   AllowOverride None
>   Require all granted
>  
> 
> 
>   #SSLRequireSSL
>   AuthType Kerberos
>   AuthName "Kerberos Login"
>   KrbAuthRealm WIN.LAN
>   Krb5KeyTab /etc/httpd/conf/ipa.keytab
>   KrbMethodNegotiate on
>   KrbMethodK5Passwd off # Set to on to query for pwd if negotiation
> failed due to no ticket available
>   KrbSaveCredentials on
>   KrbVerifyKDC on
>   KrbServiceName HTTP/ipa.my@my.lan
> 
>   AuthLDAPUrl ldaps://ipa.my.lan/dc=my,dc=lan?krbPrincipalName
>   AuthLDAPBindDN "uid=httpbind,cn=sysaccounts,cn=etc,dc=my,dc=lan"
>   AuthLDAPBindPassword "secret123abc"
>   Require ldap-group cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan
>  
> 
> 
> 
> 
> Any more ideas what I do wrong?

It was suggested that this may be due to the certificate not being
compliant with RFC 2818.  This is likely true, but I think it is not
likely to be the problem.  You can use `openssl s_client` to confirm
what certificate the server is sending:

openssl s_client -showcerts \
-servername gitserver.my.lan -connect gitserver.my.lan:443

This will dump the certificates (in PEM format), which you can copy
to a file examine with `opeenssl x509 -text < cert.pem`.

Feel free to reply with the output; I am happy to have a closer
look.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] error while installin ipa-replica with ca

[Fraser Tweedale]

On Mon, Jan 11, 2016 at 12:55:52PM +0100, Martin Kosek wrote:
> On 01/11/2016 12:51 PM, Arthur Fayzullin wrote:
> > Bingo!!!
> > that it is!!!
> > dm password contains % - symbol!
> > 
> > I am not sure but with previous versions that have not caused any problem.
> 
> Good :-)
> 
> Still, it would be nice to fix Dogtag installation procedures to not parse
> passwords that way. Endi, please just make sure there is a Dogtag Bugzilla
> filed and in some realistic milestone as this bug's root cause is not so 
> obvious.
> 
There is an existing BZ and upstream ticket:

https://bugzilla.redhat.com/show_bug.cgi?id=1283631
https://fedorahosted.org/pki/ticket/1703

> > 
> > Thanks a lot!
> > 
> > 11.01.2016 16:48, Martin Kosek пишет:
> >> On 01/11/2016 12:01 PM, Arthur Fayzullin wrote:
> >>> Good day, Colleagues!
> >>>
> >>> And Happy New Year!
> >>>
> >>> I have tried to install test stend with ipa v4.2 and 2 master-master
> >>> servers.
> >>>
> >>> files /etc/hosts on both servers contain:
> >>> 127.0.0.1   localhost localhost.localdomain localhost4
> >>> localhost4.localdomain4
> >>> ::1 localhost localhost.localdomain localhost6
> >>> localhost6.localdomain6
> >>>
> >>> 10.254.1.114 radipa00.test.ckt radipa00
> >>> 10.254.1.154 radipa01.test.ckt radipa01
> >>>
> >>> prepare key for replica server:
> >>> [root@radipa00 ipa]# ipa-replica-prepare --ip-address=10.254.1.154
> >>> radipa01.test.ckt
> >>>
> >>> copy it to replica:
> >>> [root@radipa00 ipa]# scp /var/lib/ipa/replica-info-radipa01.test.ckt.gpg
> >>> r...@radipa01.test.ckt:/var/lib/ipa/
> >>>
> >>> then on replica start installation:
> >>> [root@radipa01 ~]# ipa-replica-install --setup-ca --setup-kra
> >>> --mkhomedir --ssh-trust-dns --ip-address=10.254.1.154 --setup-dns
> >>> --forwarder=77.88.8.7 --forwarder=77.88.8.3
> >>> /var/lib/ipa/replica-info-radipa01.test.ckt.gpg
> >>>
> >>> and!!! I have got such error:
> >>>   [2/23]: configuring certificate server instance
> >>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> >>> configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
> >>> '/tmp/tmpvgc4S6'' 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-ca-install.log
> >>> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL  
> >>> /var/log/pki/pki-tomcat
> >>>   [error] RuntimeError: CA configuration failed.
> >>> Your system may be partly configured.
> >>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >>>
> >>> log file contains this error:
> >>> [root@radipa01 ~]# less /var/log/pki/pki-ca-spawn.2016050634.log
> >>> 'application_version': '[APPLICATION_VERSION]'}
> >>> 2016-01-11 15:06:34 pkispawn: ERROR... Deployment file could
> >>> not be parsed correctly.  This might be because of unescaped '%%'
> >>> characters.  You must escape '%%' characters in deployment files
> >>> (example - 'setting=foobar').
> >>> 2016-01-11 15:06:34 pkispawn: ERROR... Interpolation error
> >>> ('%' must be followed by '%' or '(', found: '%')
> >>>
> >>> I have reproduced that error several times with cenos7 and fedora23
> >>> installations.
> >>>
> >>> I am really confused if I am doing something wrong or may it is
> >>> something else...
> >>> what it can be?
> >>> 
> >>> Best wishes!
> >> CCing Endi. There used to be an error, when DM password (used also for 
> >> Dogtag)
> >> contained special characters, PKI installer choked on it. I could not find 
> >> the
> >> bug number right now.
> > 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fwd: NetworkError : invalid continuation byte with utf8 codec

[Fraser Tweedale]

On Mon, Jan 04, 2016 at 03:13:43PM +0100, Domineaux Philippe wrote:
> Hello,
> 
> Happy new year.
> 
> So the content of my /etc/locale.conf :
> 
> LANG="fr_FR.UTF-8"
> 
Happy new year to you too, and thanks for the info.

I reproduced the issue and there is a now a patch awaiting review.
Ticket: https://fedorahosted.org/freeipa/ticket/5578

Cheers,
Fraser

> -- Forwarded message --
> From: Fraser Tweedale <ftwee...@redhat.com>
> Date: 2015-12-23 5:11 GMT+01:00
> Subject: Re: [Freeipa-users] NetworkError : invalid continuation byte with
> utf8 codec
> To: Gmail <pdomine...@gmail.com>
> Cc: freeipa-users@redhat.com
> 
> 
> On Tue, Dec 22, 2015 at 08:39:09AM +0100, Gmail wrote:
> > Here are the files you ask for:
> >
> Thank you.  I see Tomcat is running in an fr_FR locale. Could you
> also provide contents of `/etc/locale.conf'?
> 
> Cheers,
> Fraser
> 
> >
> >
> > Le 22 décembre 2015 à 02:30:06, Fraser Tweedale (ftwee...@redhat.com) a
> écrit:
> >
> > On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:
> > > Hi all,
> > >
> > > When trying to install on a fresh new Centos 7 I’ve got this error :
> > >
> > > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed,
> exception: NetworkError: cannot connect to '
> https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
> decode byte 0xea in position 13: invalid continuation byte
> > > 2015-12-21T16:04:44Z ERROR cannot connect to '
> https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
> decode byte 0xea in position 13: invalid continuation byte
> > >
> > > My freeipa-server version is :  4.2.0
> > > I’m running a Centos 3.10.0-327.3.1.el7.x86_64
> > >
> > > Any idea of what goes wrong?
> > >
> > Thanks for reporting. I have not seen this error before. Could you
> > please include the following log files and I will take a closer
> > look:
> >
> > /var/log/ipaserver-install.log
> > /var/log/pki/pki-tomcat/ca/debug
> >
> > Cheers,
> > Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cockpit Integration part II - SSL certificates

[Fraser Tweedale]

On Sun, Dec 27, 2015 at 05:43:32PM +0100, Jochen Hein wrote:
> 
> Hi,
> 
> Right now cockpit still uses a locally created TLS certificate, that
> should be changed to a IPA issued certificate.  What I understood is
> that a certificate is for a host (e.g. ipa.example.com), so apache and
> cockpit should use the same certificate. Is that understanding correct?
> 
> So this is what I did:
> 
> # cp cert8.db key3.db secmod.db pwdfile.txt /tmp/
> # cd /tmp
> # pk12util -o keys.p12 -n 'Server-Cert' -d . -k /etc/httpd/alias/pwdfile.txt
> # openssl pkcs12 -in keys.p12 -out freeipa.key -nodes -clcerts
> # cp freeipa.key /etc/cockpit/ws-certs.d/freeipa.cert
> # systemctl restart cockpit.service
> 
> Now Cockpit and apache use the same certificate, but the cockpit
> certificate is not tracked by certmonger.  Any idea how that could
> work?
> 
Either Cockpit should use the certificate and private key directly
from the NSSDB so that certmonger only has to track one certificate
(but Cockpit appears to require key and cert in PEM format so this
may not be possible), or use Certmonger to issue and track a
different certificate for Cockpit (perhaps with a dedicated service
principal for Cockpit, but this is not necessary).

Use the `-f' and `-k' getcert-request(1) options to get Certmonger
to create and track PEM key and cert instead of NSSDB.

Cheers,
Fraser

> Jochen
> 
> -- 
> The only problem with troubleshooting is that the trouble shoots back.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec

[Fraser Tweedale]

On Tue, Dec 22, 2015 at 08:39:09AM +0100, Gmail wrote:
> Here are the files you ask for:
> 
Thank you.  I see Tomcat is running in an fr_FR locale. Could you
also provide contents of `/etc/locale.conf'?

Cheers,
Fraser

> 
> 
> Le 22 décembre 2015 à 02:30:06, Fraser Tweedale (ftwee...@redhat.com) a écrit:
> 
> On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:  
> > Hi all,  
> >  
> > When trying to install on a fresh new Centos 7 I’ve got this error :  
> >  
> > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, 
> > exception: NetworkError: cannot connect to 
> > 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> > decode byte 0xea in position 13: invalid continuation byte  
> > 2015-12-21T16:04:44Z ERROR cannot connect to 
> > 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> > decode byte 0xea in position 13: invalid continuation byte  
> >  
> > My freeipa-server version is :  4.2.0  
> > I’m running a Centos 3.10.0-327.3.1.el7.x86_64  
> >  
> > Any idea of what goes wrong?  
> >  
> Thanks for reporting. I have not seen this error before. Could you  
> please include the following log files and I will take a closer  
> look:  
> 
> /var/log/ipaserver-install.log  
> /var/log/pki/pki-tomcat/ca/debug  
> 
> Cheers,  
> Fraser  



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found

[Fraser Tweedale]

On Tue, Dec 22, 2015 at 10:06:55AM +0100, Karl Forner wrote:
> Hi Fraser,
> The ipa-replica-prepare ran in a adelton/freeipa-server:lastest-systemd
> docker, which I think is based on fedora 23 and contains freeIPA v 4.2.3.
> I can try to patch it, but I'm really not used to fedora, and moreover
> there's a debian/docker bug that prevents me from building the docker image
> on my computers.
> 
> Thanks,
> Karl
> 
OK, fair enough.  A couple of follow-up questions:

- Is the issue always reproducible or only some of the time?

- Are you running replica-prepare immediately after starting the
  container?  Does the issue still occur after waiting a while?

If you attach your /var/log/pki/pki-tomcat/ca/debug log it will help
pinpoint the cause and confirm/deny whether the existing patch will
fix it.

Cheers,
Fraser

> On Tue, Dec 22, 2015 at 2:46 AM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote:
> > > Hello,
> > >
> > > Running:
> > > ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v
> > > fails
> > > with
> > > ipa: DEBUG: Protocol: TLS1.2
> > > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
> > > ipa: DEBUG: request status 200
> > > ipa: DEBUG: request reason_phrase u'OK'
> > > ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT',
> > > 'content-length': '148', 'content-type': 'application/xml', 'server':
> > > 'Apache-Coyote/1.1'}
> > > ipa: DEBUG: request body ' > > standalone="no"?>1Profile
> > > caIPAserviceCert Not Found'
> > > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:   File
> > > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> > > execute
> > >
> > > The context is probably unusual:
> > > I run the command on a replica with CA from a server in freeipa v4.1.4
> > (in
> > > a adelton/freeipa-server docker)
> > > which is a freeipa v4.2.3  running in
> > > adelton/freeipa-server:lastest-systemd docker
> > >
> > > I found this ticket which looks similar:
> > > https://fedorahosted.org/freeipa/ticket/5376
> > >
> > > Is there something wrong with my replica knowing that it has been
> > > replicated from a 4.1.4 ?
> > > Is there a work-around ?
> > >
> > > Thanks
> > > Karl
> >
> > Hi Karl,
> >
> > I have a patch for Dogtag that I think will fix this issue.  Would
> > you be willing to test it?  If so, which version of Fedora/RHEL are
> > you using and I will prepare a build.
> >
> > Regards,
> > Fraser
> >
> > > --
> > > Manage your subscription for the Freeipa-users mailing list:
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > Go to http://freeipa.org for more info on the project
> >
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found

[Fraser Tweedale]

On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote:
> Hello,
> 
> Running:
> ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v
> fails
> with
> ipa: DEBUG: Protocol: TLS1.2
> ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
> ipa: DEBUG: request status 200
> ipa: DEBUG: request reason_phrase u'OK'
> ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT',
> 'content-length': '148', 'content-type': 'application/xml', 'server':
> 'Apache-Coyote/1.1'}
> ipa: DEBUG: request body ' standalone="no"?>1Profile
> caIPAserviceCert Not Found'
> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> execute
> 
> The context is probably unusual:
> I run the command on a replica with CA from a server in freeipa v4.1.4 (in
> a adelton/freeipa-server docker)
> which is a freeipa v4.2.3  running in
> adelton/freeipa-server:lastest-systemd docker
> 
> I found this ticket which looks similar:
> https://fedorahosted.org/freeipa/ticket/5376
> 
> Is there something wrong with my replica knowing that it has been
> replicated from a 4.1.4 ?
> Is there a work-around ?
> 
> Thanks
> Karl

Hi Karl,

I have a patch for Dogtag that I think will fix this issue.  Would
you be willing to test it?  If so, which version of Fedora/RHEL are
you using and I will prepare a build.

Regards,
Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec

[Fraser Tweedale]

On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:
> Hi all,
> 
> When trying to install on a fresh new Centos 7 I’ve got this error :
> 
> 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: 
> NetworkError: cannot connect to 
> 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> decode byte 0xea in position 13: invalid continuation byte
> 2015-12-21T16:04:44Z ERROR cannot connect to 
> 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't 
> decode byte 0xea in position 13: invalid continuation byte
> 
> My freeipa-server version is :  4.2.0
> I’m running a Centos 3.10.0-327.3.1.el7.x86_64
> 
> Any idea of what goes wrong?
> 
Thanks for reporting.  I have not seen this error before.  Could you
please include the following log files and I will take a closer
look:

/var/log/ipaserver-install.log
/var/log/pki/pki-tomcat/ca/debug

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Profile - Policy Set Not Found

[Fraser Tweedale]

On Wed, Dec 09, 2015 at 10:46:06AM +, wouter.hummel...@kpn.com wrote:
> Hello,
> 
> Im trying to import and use a certificate profile in IPAv4.2 on RHEL.
> 
> I've exported the default caIPAServiceCert profile and did the following 
> modification:
> < profileId=caIPAserviceCert
> ---
> > profileId=KPNWebhostingAEM
> 87c87
> < 
> policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
>  O=IPADOMAIN
> ---
> > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> >  OU=TESTAEM, O=IPADOMAIN
> 
> Profile
>   Profile ID: KPNWebhostingAEM
>   Profile description: KPN Webhosting AEM
>   Store issued certificates: TRUE
> 
> CAACL
>   ACL name: ING Intermediairs AEM Application Servers
>   Enabled: TRUE
>   Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM
>   Host Groups: xxx_accp_applications, xxx_prod_applications
> 
> Trying to request a certificate for a server
> ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k 
> /etc/pki/tls/certs/host.key  -TKPNWebhostingAEM
> 
> Results in:
> ipa-getcert list
> Number of certificates and requests being tracked: 1.
> Request ID 'mongo2':
> status: CA_UNREACHABLE
> ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed 
> request, will retry: 4301 (RPC failed at server.  Certificate operation 
> cannot be completed: FAILURE (Policy Set Not Found)).
> stuck: no
> key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key'
> certificate: type=FILE,location='/etc/pki/tls/certs/host.crt'
> CA: IPA
> issuer:
> subject:
> expires: unknown
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> 
> Since the same setup was working to request certificates on my lab 
> environment I'm at a loss what is causing the error.
> 
> Met vriendelijke groet,
> 
Hi Wouter,

I'm looking into this; stay tuned.

Fraser

> Wouter Hummelink
> Cloud Engineer
> [Description: Beschrijving: Beschrijving: cid:image003.gif@01CC7CE9.FCFEC140]
> KPN IT Solutions
> Platform Organisation Cloud Services
> Mail: wouter.hummel...@kpn.com
> Telefoon: +31 (0)6 1288 2447
> [cid:image002.png@01D0DA65.706AE4B0]
> P Save Paper - Do you really need to print this e-mail?
> *
> KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, 
> Handelsregister 52959597 Amsterdam
> The information transmitted is intended only for use by the addressee and may 
> contain confidential and/or privileged material.
> Any review, re-transmission, dissemination or other use of it, or the taking 
> of any action in reliance upon this information by persons
> and/or entities other than the intended recipient is prohibited. If you 
> received this in error, please inform the sender and/or addressee immediately
> and delete the material. Thank you.
> *
> 




> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Profile - Policy Set Not Found

[Fraser Tweedale]

Thanks for these details Wouter.

Logging at your CS.cfg, there is something wrong - the line:

subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem

should be:

subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem

What is the history of this IPA server?  Was it a fresh
ipa-server-install on RHEL 7.2; an upgrade from an earlier version
of RHEL; or an ipa-replica-install from an IPA server of an earlier
release?  Could you check the following logfiles (whichever are
present) for errors?

/var/log/ipareplica-install.log
/var/log/ipaserver-install.log
/var/log/ipaupgrade.log

Anyhow, I suggest switching to LDAPProfileSubsystem in CS.cfg,
restarting PKI and then seeing if the problem still occurs.

Cheers,
Fraser


On Fri, Dec 11, 2015 at 09:04:26AM +, wouter.hummel...@kpn.com wrote:
> ipa-admintools.x86_64 
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> ipa-client.x86_64 
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> ipa-python.x86_64 
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> ipa-server.x86_64 
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> ipa-server-dns.x86_64 
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> ipa-server-trust-ad.x86_64
>4.2.0-15.el7   
> @rhel-x86_64-server-7
> 
> pki-base.noarch   
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> pki-ca.noarch 
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> pki-kra.noarch
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> pki-server.noarch 
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> pki-symkey.x86_64 
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> pki-tools.x86_64  
>   10.2.5-6.el7
> @rhel-x86_64-server-7
> 
> CrossCertPair._000=##
> CrossCertPair._001=## CrossCertPair Import
> CrossCertPair._002=##
> CrossCertPair.ldap=internaldb
> _000=##
> _001=## Certificate Authority (CA) Configuration File
> _002=##
> accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator
> accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator
> accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator
> accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator
> admin.interface.uri=ca/admin/console/config/wizard
> agent.interface.uri=ca/agent/ca
> authType=pwd
> auths._000=##
> auths._001=## new authentication
> auths._002=##
> auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication
> auths.impl.CMCAuth.class=com.netscape.cms.authentication.CMCAuth
> auths.impl.FlatFileAuth.class=com.netscape.cms.authentication.FlatFileAuth
> auths.impl.NISAuth.class=com.netscape.cms.authentication.NISAuth
> auths.impl.PortalEnroll.class=com.netscape.cms.authentication.PortalEnroll
> auths.impl.SSLclientCertAuth.class=com.netscape.cms.authentication.SSLclientCertAuthentication
> auths.impl.TokenAuth.class=com.netscape.cms.authentication.TokenAuthentication
> auths.impl.UdnPwdDirAuth.class=com.netscape.cms.authentication.UdnPwdDirAuthentication
> auths.impl.UidPwdDirAuth.class=com.netscape.cms.authentication.UidPwdDirAuthentication
> auths.impl.UidPwdGroupDirAuth.class=com.netscape.cms.authentication.UidPwdGroupDirAuthentication
> auths.impl.UidPwdPinDirAuth.class=com.netscape.cms.authentication.UidPwdPinDirAuthentication
> auths.impl._000=##
> auths.impl._001=## authentication manager implementations
> auths.impl._002=##
> auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents
> auths.instance.AgentCertAuth.pluginName=AgentCertAuth
> 

Re: [Freeipa-users] Certificate Profile - Policy Set Not Found

[Fraser Tweedale]

On Thu, Dec 10, 2015 at 07:04:33AM +, wouter.hummel...@kpn.com wrote:
> I'll send the log as soon as I get a chance. After the mail I also tried 
> fetching a cert on another server cent7.1 that never had a cert issued. This 
> resulted in a cert conformant
> With caIpaServiceCert
> 
That is expected behaviour - only RHEL 7.2 version of Certmonger
propagates the requested profile (`-T' option) to the IPA CA.

> 
> Verzonden vanaf mijn Samsung-apparaat
> 
> 
>  Oorspronkelijk bericht ----
> Van: Fraser Tweedale <ftwee...@redhat.com>
> Datum: 2015-12-10 03:58 (GMT+01:00)
> Aan: "Hummelink, Wouter" <wouter.hummel...@kpn.com>
> Cc: freeipa-users@redhat.com
> Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found
> 
> On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote:
> > On Wed, Dec 09, 2015 at 10:46:06AM +, wouter.hummel...@kpn.com wrote:
> > > Hello,
> > >
> > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL.
> > >
> > > I've exported the default caIPAServiceCert profile and did the following 
> > > modification:
> > > < profileId=caIPAserviceCert
> > > ---
> > > > profileId=KPNWebhostingAEM
> > > 87c87
> > > < 
> > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> > >  O=IPADOMAIN
> > > ---
> > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> > > >  OU=TESTAEM, O=IPADOMAIN
> > >
> > > Profile
> > >   Profile ID: KPNWebhostingAEM
> > >   Profile description: KPN Webhosting AEM
> > >   Store issued certificates: TRUE
> > >
> > > CAACL
> > >   ACL name: ING Intermediairs AEM Application Servers
> > >   Enabled: TRUE
> > >   Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM
> > >   Host Groups: xxx_accp_applications, xxx_prod_applications
> > >
> > > Trying to request a certificate for a server
> > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k 
> > > /etc/pki/tls/certs/host.key  -TKPNWebhostingAEM
> > >
> > > Results in:
> > > ipa-getcert list
> > > Number of certificates and requests being tracked: 1.
> > > Request ID 'mongo2':
> > > status: CA_UNREACHABLE
> > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed 
> > > request, will retry: 4301 (RPC failed at server.  Certificate operation 
> > > cannot be completed: FAILURE (Policy Set Not Found)).
> > > stuck: no
> > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key'
> > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt'
> > > CA: IPA
> > > issuer:
> > > subject:
> > > expires: unknown
> > > pre-save command:
> > > post-save command:
> > > track: yes
> > > auto-renew: yes
> > >
> > > Since the same setup was working to request certificates on my lab 
> > > environment I'm at a loss what is causing the error.
> > >
> > > Met vriendelijke groet,
> > >
> > Hi Wouter,
> >
> > I'm looking into this; stay tuned.
> >
> OK, I could not reproduce.  Is the issue reproducible for you?  Did
> you execute the commands by hand or as part of a script?  Can you
> provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)?
> 
> Cheers,
> Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Profile - Policy Set Not Found

[Fraser Tweedale]

On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote:
> On Wed, Dec 09, 2015 at 10:46:06AM +, wouter.hummel...@kpn.com wrote:
> > Hello,
> > 
> > Im trying to import and use a certificate profile in IPAv4.2 on RHEL.
> > 
> > I've exported the default caIPAServiceCert profile and did the following 
> > modification:
> > < profileId=caIPAserviceCert
> > ---
> > > profileId=KPNWebhostingAEM
> > 87c87
> > < 
> > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> >  O=IPADOMAIN
> > ---
> > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> > >  OU=TESTAEM, O=IPADOMAIN
> > 
> > Profile
> >   Profile ID: KPNWebhostingAEM
> >   Profile description: KPN Webhosting AEM
> >   Store issued certificates: TRUE
> > 
> > CAACL
> >   ACL name: ING Intermediairs AEM Application Servers
> >   Enabled: TRUE
> >   Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM
> >   Host Groups: xxx_accp_applications, xxx_prod_applications
> > 
> > Trying to request a certificate for a server
> > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k 
> > /etc/pki/tls/certs/host.key  -TKPNWebhostingAEM
> > 
> > Results in:
> > ipa-getcert list
> > Number of certificates and requests being tracked: 1.
> > Request ID 'mongo2':
> > status: CA_UNREACHABLE
> > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed 
> > request, will retry: 4301 (RPC failed at server.  Certificate operation 
> > cannot be completed: FAILURE (Policy Set Not Found)).
> > stuck: no
> > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key'
> > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt'
> > CA: IPA
> > issuer:
> > subject:
> > expires: unknown
> > pre-save command:
> > post-save command:
> > track: yes
> > auto-renew: yes
> > 
> > Since the same setup was working to request certificates on my lab 
> > environment I'm at a loss what is causing the error.
> > 
> > Met vriendelijke groet,
> > 
> Hi Wouter,
> 
> I'm looking into this; stay tuned.
> 
OK, I could not reproduce.  Is the issue reproducible for you?  Did
you execute the commands by hand or as part of a script?  Can you
provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)?

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate Profile - Policy Set Not Found

[Fraser Tweedale]

On Thu, Dec 10, 2015 at 12:58:05PM +1000, Fraser Tweedale wrote:
> On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote:
> > On Wed, Dec 09, 2015 at 10:46:06AM +, wouter.hummel...@kpn.com wrote:
> > > Hello,
> > > 
> > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL.
> > > 
> > > I've exported the default caIPAServiceCert profile and did the following 
> > > modification:
> > > < profileId=caIPAserviceCert
> > > ---
> > > > profileId=KPNWebhostingAEM
> > > 87c87
> > > < 
> > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> > >  O=IPADOMAIN
> > > ---
> > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> > > >  OU=TESTAEM, O=IPADOMAIN
> > > 
> > > Profile
> > >   Profile ID: KPNWebhostingAEM
> > >   Profile description: KPN Webhosting AEM
> > >   Store issued certificates: TRUE
> > > 
> > > CAACL
> > >   ACL name: ING Intermediairs AEM Application Servers
> > >   Enabled: TRUE
> > >   Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM
> > >   Host Groups: xxx_accp_applications, xxx_prod_applications
> > > 
> > > Trying to request a certificate for a server
> > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k 
> > > /etc/pki/tls/certs/host.key  -TKPNWebhostingAEM
> > > 
> > > Results in:
> > > ipa-getcert list
> > > Number of certificates and requests being tracked: 1.
> > > Request ID 'mongo2':
> > > status: CA_UNREACHABLE
> > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed 
> > > request, will retry: 4301 (RPC failed at server.  Certificate operation 
> > > cannot be completed: FAILURE (Policy Set Not Found)).
> > > stuck: no
> > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key'
> > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt'
> > > CA: IPA
> > > issuer:
> > > subject:
> > > expires: unknown
> > > pre-save command:
> > > post-save command:
> > > track: yes
> > > auto-renew: yes
> > > 
> > > Since the same setup was working to request certificates on my lab 
> > > environment I'm at a loss what is causing the error.
> > > 
> > > Met vriendelijke groet,
> > > 
> > Hi Wouter,
> > 
> > I'm looking into this; stay tuned.
> > 
> OK, I could not reproduce.  Is the issue reproducible for you?  Did
> you execute the commands by hand or as part of a script?  Can you
> provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)?
>
Oh, and did you make any changes to the profile configuration
besides those you mentioned; the profileId and Subject Name pattern?

> 
> Cheers,
> Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and LetsEncrypt Question

[Fraser Tweedale]

On Mon, Nov 30, 2015 at 02:46:13PM +0200, Alexander Bokovoy wrote:
> On Mon, 30 Nov 2015, Günther J. Niederwimmer wrote:
> >Hello ,
> >
> >I have the question, know any from the FreeIPA "Gurus" ;-), are the new
> >upcoming LetsEncrypt Certificates compatible and working with FreeIPA?
> We have plans to support issuing certificates via Let's Encrypt.
> 
Günther, what are your specific wishes - to automatically acquire LE
certs for FreeIPA server's HTTP and LDAP?  Arbitrary hosts or
services that are managed by FreeIPA?

> However, right now Let's encrypt only issues server certificates, not
> CA roots, so you cannot use them to bootstrap IPA CA.
>
This will probably always be the case.

Cheers,
Fraser

> -- 
> / Alexander Bokovoy
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CA Certificate Profile

[Fraser Tweedale]

On Wed, Nov 25, 2015 at 12:42:28PM +, wouter.hummel...@kpn.com wrote:
> Hello,
> 
> For one of my customer projects I need server certificates that have an OU 
> component in de the subject. I tried making a certificate profile that is 
> identical to the default caIPAServiceCert except for the first section. I 
> changed the constraint to include OU and the default to include an OU, 
> however that doesn't appear to be a valid field.
> 
> policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
> policyset.serverCertSet.1.constraint.name=Subject Name Constraint
> policyset.serverCertSet.1.constraint.params.accept=true
> policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,OU=[^,],.+
> policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
> policyset.serverCertSet.1.default.name=Subject Name Default
> policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,OU=$request.req_subject_name.ou$,O=LINUX.TEST.INFRA.LOCAL
> 
> I can see the CSR that comes into pki include the OU field when requested 
> like following.
> 
> ipa-getcert request -I test -k /etc/pki/tls/certs/server.key -f 
> /etc/pki/tls/certs/server.cert -N "CN=$(hostname 
> -f),OU=Test,O=LINUX.TEST.INFRA.LOCAL" -K host/$(hostname -f) -w -T 
> KPNWebhostingServiceCert
> 
> The debug log however doesn't show a key like request.req_subject_name.ou, 
> and results in a nasty error on the certmonger side:
> Request ID 'test':
> status: CA_UNREACHABLE
> ca-error: Server at https://ipaserver.ipa.local/ipa/xml failed 
> request, will retry: 4301 (RPC failed at server.  Certificate operation 
> cannot be completed: unknown(3) (Request Rejected - {0})).
> stuck: no
> key pair storage: type=FILE,location='/etc/pki/tls/certs/server.key'
> certificate: type=FILE,location='/etc/pki/tls/certs/server.cert'
> CA: IPA
> issuer:
> subject:
> expires: unknown
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> 
Hi, thanks for your detailed report.

Dogtag currently only supports $request.req_subject_name.{cn,uid}$.
The error occurs because Dogtag does not populate the
$request.req_subject_name.ou$ substitution variable thus the
formatting of the subject name fails.

If the OU is to be the same for all certificates, or if there are
only a handful of values, you can make different profiles with
constant OUs.

If that is not adequate, we can file an RFE to add support for other
DN components including OU.

(Also, note that FreeIPA currently does not perform any validation
of the OU in the CSR against the target principal's entry).

Cheers,
Fraser

> Met vriendelijke groet,
> 
> Wouter Hummelink
> Cloud Engineer
> [Description: Beschrijving: Beschrijving: cid:image003.gif@01CC7CE9.FCFEC140]
> KPN IT Solutions
> Platform Organisation Cloud Services
> Mail: wouter.hummel...@kpn.com
> Telefoon: +31 (0)6 1288 2447
> [cid:image002.png@01D0DA65.706AE4B0]
> P Save Paper - Do you really need to print this e-mail?
> *
> KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, 
> Handelsregister 52959597 Amsterdam
> The information transmitted is intended only for use by the addressee and may 
> contain confidential and/or privileged material.
> Any review, re-transmission, dissemination or other use of it, or the taking 
> of any action in reliance upon this information by persons
> and/or entities other than the intended recipient is prohibited. If you 
> received this in error, please inform the sender and/or addressee immediately
> and delete the material. Thank you.
> *
> 




> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved)

[Fraser Tweedale]

On Fri, Nov 13, 2015 at 12:00:16PM +0100, Martin Kosek wrote:
> On 11/13/2015 11:14 AM, Terry John wrote:
> >>On 11/12/2015 04:51 PM, Terry John wrote:
> >>>I got a core dump of certmonger failing user abrt but it's huge. Is there 
> >>>any particular part that would be useful.
> >
> >>CCing Nalin and David for the core dump. More below.
> >
> >>On 11/12/2015 02:17 PM, Terry John wrote:
> I had a working freeipa setup on a CentOS release 6.7 machine.  All was 
> well until I did a yum update. Now I have multiple issue apparently based 
> around the CMS (Service Unavailable) issue.
> My current version of ipa-server is 3.0.0-47 Certmonger crashes with
> a segmentation fault at boot time and crashes every time I try to restart 
> it when ipa is running.
> >>
> >
> >
> ># ipa cert-status
> >Request id: 20140417164153
> >ipa: ERROR: Certificate operation cannot be completed: Unable to
> >communicate with CMS (Service Unavailable) # service certmonger
> >status certmonger (pid  3030) is running...
> >>>
> It looks like PKI cannot be contacted. I would recommend checking 
> /var/log/httpd/error_log, it may have more details. I would also 
> recommend checking "ipa cert-show 1", it will probably fail with the same 
> bug.
> >>>Yes ipa cert-show 1 does show the same thing # ipa cert-show 1
> >>>ipa: ERROR: Certificate operation cannot be completed: Unable to
> >>>communicate with CMS (Service Unavailable)
> >>>
> Next steps may include checking that dogtag service really runs, there is 
> no SELinux AVC. If neither of this helps, you can check PKI logs 
> /var/log/pki... to see what went wrong.
> >>>I'm pretty certain the dogtag service is not running
> >
> >Then you have your lucky winner! :-)
> >
> Some pointers to logs are for example here:
> http://www.freeipa.org/page/Troubleshooting#Server_Installation
> >>
> >>>/var/log/pki-ca/catalina.out contains the lines at boot time:
> >
> >
> >>>SEVERE: Error deploying web application directory ca
> >>>java.lang.UnsupportedClassVersionError: 
> >>>com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported 
> >>>major.minor version 51.0 (unable to load class 
> >>>com.netscape.cms.servlet.filter.AgentRequestFilter)   at  
> >>>org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> 
> >>>lassLoader.java:2334) lots of traceback
> >>>
> >>>/var/log/pki-ca/system is empty
> >>>/var/log/pki-ca/debug has nothing new for 2 days
> >
> >>CCing Fraser. This is a wild guess, but maybe you updated your java to 
> >>java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS:
> >
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1262516
> >
> >>java would need to be switched with "alternate" to pre-1.8.0 version if 
> >>this is the case.
> >
> >The java version was the problem.
> 
> Good! Fraser, can we improve anything in pki-core, so that wrong java
> version issue like this one does not occur? IIRC, pki-core in RHEL-6.x was
> updated to somehow deal with java 1.8.0 (conflict), not sure if lower
> versions are also covered.
> 
AFAICT there is no such protection.  It seems to be more of an
unspoken "don't do that".

I guess the right approach when an unsupported alternative is
selected is to explicitly use a supported one.  I'm not sure what's
involved in making that change or whether it is worth the effort.

Adding pki-devel for comment from those with packaging experience.

Cheers,
Fraser

> >Luckily I have a java expert to hand and explained that major.minor version 
> >51.0 corresponds to java 7
> >http://stackoverflow.com/questions/9170832/list-of-java-class-file-format-major-version-numbers
> >When I did
> ># ps ax | grep java I got"
> >1460 ? Sl   1:21 /usr/java/default/bin/java -Djavax.sql.Da...
> ># /usr/java/default/bin/java -version
> >java version "1.6.0_31"
> >Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> >Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> >
> >I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the 
> >/usr/java/default/bin is all from java-1.6.0-openjdk
> >
> >I have renamed /usr/java/default/bin/java to javaold and done
> ># ln -s /usr/bin/java /usr/java/default/bin/java
> ># /usr/java/default/bin/java -version
> >java version "1.7.0_91"
> >OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00)
> >OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
> 
> This may work, but looks a bit hacky. I think the right way is to use
> "alternate" program I mentioned earlier to let you choose the right version
> of the java executable and/or libraries.
> 
> >After a reboot FreeIPA works properly which is great but I'm wondering if 
> >there is a better fix though since all the other executables in are from the 
> >1.6 version. I can't find a corresponding location for 1.7 executables.
> 
> The "alternate" approach should "just work". I am glad you made the instance
> working again!
> 
> >
> >Thanks 

Re: [Freeipa-users] SSO Git http smart server and freeipa group authentication

[Fraser Tweedale]

On Wed, Nov 11, 2015 at 10:26:11PM +0100, John Obaterspok wrote:
> Thanks Simo & Fraser,
> 
> Creating a .netrc file on the client computer with according to the SO
> postings with below content made things work perfectly!
> machine gitserver.my.lan  username '' password ''
> machine gitserver username '' password ''
> 
> I would like to use TLS and I've made it work by turning off ssl validation
> in git:
> git config --global http.sslVerify false
> 
> If I would like to use ssl validation, is there some way to use a
> certificate for the CNAME? Seems I can only add certificate (at least from
> the UI) for a valid principal?
> 
> (I'm using freeipa-server 4.2.3 on F23)
> 
> Regards,
> 
> -- john
> 
Hi John, glad to hear of your success.

For a certificate, you can add the (bogus) host and the principal
and then issue a certificate in the normal way.

  $ ipa host-add gitserver.my.lan
  $ ipa service-add HTTP/gitserver.my.lan

I'm not sure if there's a way to add the principal directly, absent
a corresponding host.  If someone knows how please speak up!

Cheers,
Fraser

> 
> 2015-11-08 23:55 GMT+01:00 Simo Sorce :
> 
> > On 08/11/15 08:07, John Obaterspok wrote:
> >
> >> Hello,
> >>
> >> Anyone got git-http-backend working with freeipa group auhentication and
> >> would like to share their apache .conf file?
> >>
> >>
> >> I've tried this on the IPA server with a dummy git repository setup in
> >> /opt/gitrepos/test1.git
> >> gitserver.my.lan is a CNAME for ipaserver.my.lan
> >>
> >> First, "git clone http://gitserver.my.lan/test1.git; prompts (even
> >> though I
> >> have a ticket) for user+pwd but still fails.
> >>
> >> Any suggestions are welcome!
> >>
> >> -- john
> >>
> >>
> >> 
> >>
> >>  DocumentRoot /opt/gitrepos
> >>
> >>  # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?'
> >>  # restorecon -R -v /opt/gitrepos
> >>
> >>  SetEnv GIT_PROJECT_ROOT /opt/gitrepos
> >>  SetEnv GIT_HTTP_EXPORT_ALL
> >>  SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
> >>  ScriptAlias / /usr/libexec/git-core/git-http-backend/
> >>  ServerName gitserver.my.lan
> >>
> >>  
> >>  Options Indexes
> >>  AllowOverride None
> >>  Require all granted
> >>  
> >>
> >>  
> >>  Options Indexes
> >>  AllowOverride None
> >>  Require all granted
> >>  
> >>
> >>  
> >>  AuthType Kerberos
> >>  AuthName "Kerberos Login"
> >>  KrbAuthRealm MY.LAN
> >>  Krb5KeyTab /etc/httpd/conf/ipa.keytab
> >>  KrbMethodNegotiate on
> >>  KrbMethodK5Passwd off
> >>  KrbSaveCredentials on
> >>  KrbVerifyKDC on
> >>  KrbServiceName HTTP
> >>
> >>  AuthLDAPUrl
> >> ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName
> >>  Require ldap-group cn=ipausers,dc=my,dc=lan
> >>
> >
> > This should probably be somehting like:
> > cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan
> >
> > Although you should probably create a git specific group, especially if
> > you want it to be a posix group that can own files (ipausers is not a posix
> > group and we are actually trying to phase it out)
> >
> > Also you are not doing LDAP authentication, you only want to do
> > authorization, and for that you may want to actually use nsswitch based
> > authorization which can be cached by sssd and not a query out to LDAP for
> > each connection.
> > Unfortunately the basic Apache modules do not support system group
> > authentication directly, so what you may do instead is to have a cron job
> > that do the following:
> > getent group git-users | cut -d: -f1,4 |tr ',' ' ' > /my/authorization/file
> >
> > And in apache have set the following directives instead of the above two:
> > AuthGroupFile /my/authorization/file
> > Require group git-users
> >
> > HTH,
> > Simo
> >
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> >

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Wed, Nov 11, 2015 at 02:50:20PM -0800, Prasun Gera wrote:
> I'll try this on an aws instance and report. Some googling also suggests
> that the additional step of "pk12util -i ipa.example.com.p12 -d
> /etc/httpd/alias" is needed, which is similar to what you suggested. A few
> more questions:
> 1) How would renewals work ? the pem files can be renewed on expiration
> from LE's client. Would I need to run the exact same steps every time ?
>
Ideally, Certmonger will learn how to renew the certs with Let's
Encrypt CA, by satisfying "Proof of Possession" challenges.

> 2) Do expired ones need to be removed from the db in some way before
> renewed ones can be added ?
>
IIRC you can just add the new cert.

> 3) If httpd's certs expire, it won't affect any other functionality apart
> from the webui right ? Are there any other side effects ? I won't be using
> this for ldap certs.
>
RPC API is also served over HTTP; the `ipa' CLI program uses this
API so it will be affected.

> 4) How would I revert to IPA signed certs with automatic renewal if I want
> to ? i.e. Reverting to stock configuration
> 
Issue and track certs with Certmonger, and update HTTP configuration
to use the new cert.  If you want to try this please write it up and
contribute to wiki!

Thanks,
Fraser

> 
> On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden <rcrit...@redhat.com> wrote:
> 
> > Fraser Tweedale wrote:
> >
> >> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> >>
> >>> You are right in that the fullchain.pem doesn't have the root
> >>> certificate.
> >>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> >>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and
> >>> Subject:
> >>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> >>> certificate for DST Root CA X3 from
> >>> https://www.identrust.com/certificates/trustid/root-download-x3.html,
> >>> which
> >>> is self signed from what I can tell. The issuer and the subject are the
> >>> same. I added that to the fullchain, and the command seemed to work.
> >>> However, it messed something up, and httpd didn't start after that. httpd
> >>> error log had "Unable to verify certificate 'Signing-Cert'. Add
> >>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> >>> problem can be resolved ". I added that to nss.conf, and ipactl started
> >>> successfully after that. However, the webui hadn't configured the
> >>> certificates properly. At this point, I just restored my backups
> >>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> >>> where things were earlier. I think it would be better to do these
> >>> experiments on a test bed first.
> >>>
> >>> I am at a loss, and must have missed something.  The purpose of this
> >> command is to be able to install 3rd party certificates, yet the
> >> code is expecting the certs to be signed by the IPA CA?
> >>
> >> Can someone explain what is going on here?
> >>
> >
> > That isn't the problem. It doesn't require the IPA CA at all. It just
> > checks that the root CA which issued the server cert is available (looks
> > for subject == issuer). It would appear that something wasn't imported into
> > the Apache NSS db.
> >
> > You'd need to re-run the import and then look at the Apache NSS database
> > to ensure that the entire cert chain was imported with the proper trust
> > which apparently it wasn't.
> >
> > # certutil -L -d /etc/httpd/alias
> >
> > The entire chain should be there, probably with trust like CT,, or C,,.
> >
> > To fix trust:
> >
> > # certutil -M -n "" -t CT,, -d /etc/httpd/alias
> >
> > To add missing certs:
> >
> > # certutil -A -n "<nickname"> -t CT,, -d /etc/httpd/alias -i -i
> > /path/to/pem
> >
> > Validate the web server cert. Use whatever nickname is appropriate for you:
> >
> > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
> >
> > The more details you have on what you did to fix this the better as that
> > can be used to generate a new bug to fix this upstream.
> >
> > rob
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] mastercrl files

[Fraser Tweedale]

On Wed, Nov 11, 2015 at 03:41:34PM -0500, Rob Crittenden wrote:
> Martin Kosek wrote:
> >On 11/10/2015 10:59 PM, Fraser Tweedale wrote:
> >>On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote:
> >>>hi,
> >>>
> >>>do we need to keep all the MasterCRL-MMDD-HHMMSS.der files or can we
> >>>purge them on a regular basis (say, keep 60 days dump the rest)?
> >>>
> >>>$ ls -l | wc -l
> >>>3621
> >>>
> >>>this is in a server installed 3 years ago.
> >>>
> >>>--
> >>>Groeten,
> >>>natxo
> >>>
> >>Hi Natxo,
> >>
> >>You can purge them.  I am not sure why we keep the old ones around;
> >>can someone fill me in?
> >
> >This was not touched loong ago. CCing Rob in case he has an idea, but if
> >not - you are probably the best person to improve it :-)
> >
> 
> I don't know if I considered this at all back in the day but I agree it is
> probably up to dogtag to prune this directory. The files to keep should be
> based on the generation schedule. I can't think of any value an older CRL
> might provide though perhaps that should be configurable too.
> 
> rob
>
I filed tickets:

https://fedorahosted.org/pki/ticket/1696
https://fedorahosted.org/freeipa/ticket/5447

I do not think it is a high priority because it can be achieved with
a simple cron job.  But we should change the default behaviour
eventually.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> I tried using let's encrypt's certs manually, but I think I'm missing
> something. Let's encrypt creates the following files : cert.pem  chain.pem
>  fullchain.pem  privkey.pem. I was trying to follow
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i
> wasn't able to get it to work. That page says, "The certificate in
> mysite.crt must be signed by the CA used when installing FreeIPA." Since my
> ipa installation uses the default internal CA, how do I get lets encrypt's
> certs signed by the ipa CA ? Is that the missing step ?
> 
I do not think that text is correct, in the case of a
publicy-trusted certificate (i.e. the server cert is chained to a
trusted issuer).

Just ignore that text and follow the steps.  Does it work?

Cheers,
Fraser

> On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com> wrote:
> 
> > Thanks for the discussion. If someone can update the documentation with
> > mozilla style old, intermediate and modern cipher lists for mod_nss, that
> > would be great. Better still would be to add that option to the installer
> > scripts so that you can choose it during installation. Integrating that in
> > the package would also have the added benefit of settings remaining up to
> > date without manual intervention as standards evolve.
> >
> > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftwee...@redhat.com>
> > wrote:
> >
> >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> >> > Prasun Gera wrote:
> >> > > Thanks. After the changes, most things seem to be in order. I see two
> >> > > orange flags though:
> >> > >
> >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> >> DANGER* (more
> >> > > info
> >> > > <
> >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> >> >)
> >> >
> >> > Renegotiation is required for the CA so you need to leave this enabled.
> >> >
> >> > > Session resumption (caching)*No (IDs assigned but not
> >> accepted)*
> >> >
> >> > I'll need to look at this in more detail. At worst it would slow new
> >> > connection performance slightly as it means every connection requires a
> >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> >> >
> >> Definitely not a show-stopper.  The main reason this is an "orange"
> >> alert in SSLLabs is because the server is assigning Session IDs but
> >> then ignoring them; although confusing it is a fairly common default
> >> behaviour and doesn't cause any issues with compliant client
> >> implementation
> >>
> >> > rob
> >> >
> >> > >
> >> > > Are these relevant/serious ? Can they be mitigated ?
> >> > >
> >> > >
> >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcrit...@redhat.com
> >> > > <mailto:rcrit...@redhat.com>> wrote:
> >> > >
> >> > > Prasun Gera wrote:
> >> > > > Yes, that's what I was planning to do. i.e. Convert cipher
> >> names from
> >> > > > SSL to NSS. I wasn't sure about the other settings though. Is
> >> there an
> >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly,
> >> are there
> >> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow
> >> using
> >> > > > generated DH parameters instead of standard ones ? For SSL, the
> >> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
> >> DHParameters
> >> > > > "{path to dhparams.pem}"' after generating the params.
> >> > >
> >> > > NSS does not let the user specify cipher order. It uses its own
> >> internal
> >> > > sorting from strongest to weakest.
> >> > >
> >> > > HSTS is a header and not dependent upon SSL provider.
> >> > >
> >> > > mod_nss doesn't support DH ciphers.
> >> > >
> >> > > rob
> >> > >
> >> > > >
> >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
> >> ftwee...@redhat.com <mailto:ftwee...@redhat.com>
> >> > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> No it didn't quite work.
> 
> I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> 
> which gives The full certificate chain is not present in
> /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> example.com/fullchain.pem
> 
It looks like this error is triggered when there is no self-signed
certificate in the trust chain (fullchain.pem).  Could you confirm
that this is the case, and if so, could you try appending the root
certificate to fullchain.pem and trying again?

It may be that ipa-server-certinstall assumes that your server certs
are signed by the same CA as your IPA CA certificate, which need not
be the case.

> 
> On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> 
> > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > > I tried using let's encrypt's certs manually, but I think I'm missing
> > > something. Let's encrypt creates the following files : cert.pem
> > chain.pem
> > >  fullchain.pem  privkey.pem. I was trying to follow
> > > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> > but i
> > > wasn't able to get it to work. That page says, "The certificate in
> > > mysite.crt must be signed by the CA used when installing FreeIPA." Since
> > my
> > > ipa installation uses the default internal CA, how do I get lets
> > encrypt's
> > > certs signed by the ipa CA ? Is that the missing step ?
> > >
> > I do not think that text is correct, in the case of a
> > publicy-trusted certificate (i.e. the server cert is chained to a
> > trusted issuer).
> >
> > Just ignore that text and follow the steps.  Does it work?
> >
> > Cheers,
> > Fraser
> >
> > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com>
> > wrote:
> > >
> > > > Thanks for the discussion. If someone can update the documentation with
> > > > mozilla style old, intermediate and modern cipher lists for mod_nss,
> > that
> > > > would be great. Better still would be to add that option to the
> > installer
> > > > scripts so that you can choose it during installation. Integrating
> > that in
> > > > the package would also have the added benefit of settings remaining up
> > to
> > > > date without manual intervention as standards evolve.
> > > >
> > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftwee...@redhat.com>
> > > > wrote:
> > > >
> > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > > >> > Prasun Gera wrote:
> > > >> > > Thanks. After the changes, most things seem to be in order. I see
> > two
> > > >> > > orange flags though:
> > > >> > >
> > > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > > >> DANGER* (more
> > > >> > > info
> > > >> > > <
> > > >>
> > https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > > >> >)
> > > >> >
> > > >> > Renegotiation is required for the CA so you need to leave this
> > enabled.
> > > >> >
> > > >> > > Session resumption (caching)*No (IDs assigned but not
> > > >> accepted)*
> > > >> >
> > > >> > I'll need to look at this in more detail. At worst it would slow new
> > > >> > connection performance slightly as it means every connection
> > requires a
> > > >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> > > >> >
> > > >> Definitely not a show-stopper.  The main reason this is an "orange"
> > > >> alert in SSLLabs is because the server is assigning Session IDs but
> > > >> then ignoring them; although confusing it is a fairly common default
> > > >> behaviour and doesn't cause any issues with compliant client
> > > >> implementation
> > > >>
> > > >> > rob
> > > >> >
> > > >> > >
> > > >> > > Are these relevant/serious ? Can they be mitigated ?
> > > >> > >
> > > >> > >
> > > >> > > 

Re: [Freeipa-users] mastercrl files

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 07:02:42PM +0100, Natxo Asenjo wrote:
> hi,
> 
> do we need to keep all the MasterCRL-MMDD-HHMMSS.der files or can we
> purge them on a regular basis (say, keep 60 days dump the rest)?
> 
> $ ls -l | wc -l
> 3621
> 
> this is in a server installed 3 years ago.
> 
> --
> Groeten,
> natxo
>
Hi Natxo,

You can purge them.  I am not sure why we keep the old ones around;
can someone fill me in?

Cheers,
Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> You are right in that the fullchain.pem doesn't have the root certificate.
> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> certificate for DST Root CA X3 from
> https://www.identrust.com/certificates/trustid/root-download-x3.html, which
> is self signed from what I can tell. The issuer and the subject are the
> same. I added that to the fullchain, and the command seemed to work.
> However, it messed something up, and httpd didn't start after that. httpd
> error log had "Unable to verify certificate 'Signing-Cert'. Add
> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> problem can be resolved ". I added that to nss.conf, and ipactl started
> successfully after that. However, the webui hadn't configured the
> certificates properly. At this point, I just restored my backups
> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> where things were earlier. I think it would be better to do these
> experiments on a test bed first.
> 
I am at a loss, and must have missed something.  The purpose of this
command is to be able to install 3rd party certificates, yet the
code is expecting the certs to be signed by the IPA CA?

Can someone explain what is going on here?

Fraser

> 
> On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera <prasun.g...@gmail.com> wrote:
> 
> >
> >
> > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale <ftwee...@redhat.com>
> > wrote:
> >
> >> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> >> > No it didn't quite work.
> >> >
> >> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> >> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> >> >
> >> > which gives The full certificate chain is not present in
> >> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> >> > example.com/fullchain.pem
> >> >
> >> It looks like this error is triggered when there is no self-signed
> >> certificate in the trust chain (fullchain.pem).  Could you confirm
> >> that this is the case, and if so, could you try appending the root
> >> certificate to fullchain.pem and trying again?
> >>
> >>
> >
> > I'm sorry, I didn't quite follow. Can you elaborate what I need to append
> > to what ?
> >
> > From let's encrypt's documentation:
> >
> > cert.pem
> > Server certificate only.
> >
> > This is what Apache needs for SSLCertificateFile.
> >
> > chain.pem
> > All certificates that need to be served by the browser excluding server
> > certificate, i.e. root and intermediate certificates only.
> >
> > This is what Apache needs for SSLCertificateChainFile.
> >
> > fullchain.pem
> > All certificates, including server certificate. This is concatenation of
> > chain.pem and cert.pem.
> >
> > This is what nginx needs for ssl_certificate.
> >
> >
> > So fullchain.pem should have all the relevant bits right ? Do you mean I
> > should append ipa's root cert from /etc/ipa/ca.crt ?
> >
> >
> >
> >
> >
> >> It may be that ipa-server-certinstall assumes that your server certs
> >> are signed by the same CA as your IPA CA certificate, which need not
> >> be the case.
> >>
> >> >
> >> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com>
> >> > wrote:
> >> >
> >> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> >> > > > I tried using let's encrypt's certs manually, but I think I'm
> >> missing
> >> > > > something. Let's encrypt creates the following files : cert.pem
> >> > > chain.pem
> >> > > >  fullchain.pem  privkey.pem. I was trying to follow
> >> > > >
> >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> >> > > but i
> >> > > > wasn't able to get it to work. That page says, "The certificate in
> >> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
> >> Since
> >> > > my
> >> > > > ipa installation uses the default internal CA, how do I get lets
> >> > > encrypt's
> >> > >

Re: [Freeipa-users] SSO Git http smart server and freeipa group authentication

[Fraser Tweedale]

On Sun, Nov 08, 2015 at 02:07:23PM +0100, John Obaterspok wrote:
> Hello,
> 
> Anyone got git-http-backend working with freeipa group auhentication and
> would like to share their apache .conf file?
> 
> 
> I've tried this on the IPA server with a dummy git repository setup in
> /opt/gitrepos/test1.git
> gitserver.my.lan is a CNAME for ipaserver.my.lan
> 
> First, "git clone http://gitserver.my.lan/test1.git; prompts (even though I
> have a ticket) for user+pwd but still fails.
> 
> Any suggestions are welcome!
> 
> -- john
> 
> 
> 
> 
> DocumentRoot /opt/gitrepos
> 
> # semanage fcontext -a -t git_rw_content_t '/opt/gitrepos(/.*)?'
> # restorecon -R -v /opt/gitrepos
> 
> SetEnv GIT_PROJECT_ROOT /opt/gitrepos
> SetEnv GIT_HTTP_EXPORT_ALL
> SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
> ScriptAlias / /usr/libexec/git-core/git-http-backend/
> ServerName gitserver.my.lan
> 
> 
> Options Indexes
> AllowOverride None
> Require all granted
> 
> 
> 
> Options Indexes
> AllowOverride None
> Require all granted
> 
> 
> 
> AuthType Kerberos
> AuthName "Kerberos Login"
> KrbAuthRealm MY.LAN
> Krb5KeyTab /etc/httpd/conf/ipa.keytab
> KrbMethodNegotiate on
> KrbMethodK5Passwd off
> KrbSaveCredentials on
> KrbVerifyKDC on
> KrbServiceName HTTP
> 
> AuthLDAPUrl
> ldap://ipaserver.my.lan:389/dc=my,dc=lan?krbPrincipalName
> Require ldap-group cn=ipausers,dc=my,dc=lan
> # Allow anyone authenticated users that are ina ipausers
> group to clone
> 
> 
> ~
> ~
> ~
Hi John,

Have a look at this Stack Overflow question:
http://stackoverflow.com/questions/32788405/how-to-force-git-2-5-http-transport-prefer-spnego-over-basic-authentication

Make sure you provide a (fake) username to trigger the SPNEGO
authentication code.  If this does not work please run with
`GIT_CURL_VERBOSE=1' in environment to reveal what is going on
behind the scenes.

Cheers,
Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA Json Selfsigned certificate

[Fraser Tweedale]

On Fri, Nov 06, 2015 at 01:28:41PM +0100, Matt . wrote:
> Hi guys,
> 
> I'm testing out some installation and want to update my docs.
> 
> I'm using a self signed cert and need to talk to the json/api.
> 
> Which certs do I need to combine for my request, as I need an issuer too.
> 
> The /etc/ipa/ca.crt combined with an export of the webcert ?
> 
> Matt
> 
Is the HTTP certificate signed by /etc/ipa/ca.crt?  If so, you only
need to make sure that /etc/ipa/ca.crt is a trusted root.

Cheers,
Fraser

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> Prasun Gera wrote:
> > Thanks. After the changes, most things seem to be in order. I see two
> > orange flags though:
> > 
> > Secure Client-Initiated Renegotiation   *Supported*   *DoS DANGER* (more
> > info
> > <https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks>)
> 
> Renegotiation is required for the CA so you need to leave this enabled.
> 
> > Session resumption (caching)*No (IDs assigned but not accepted)*
> 
> I'll need to look at this in more detail. At worst it would slow new
> connection performance slightly as it means every connection requires a
> full SSL/TLS handshake. I don't think it's a show-stopper.
> 
Definitely not a show-stopper.  The main reason this is an "orange"
alert in SSLLabs is because the server is assigning Session IDs but
then ignoring them; although confusing it is a fairly common default
behaviour and doesn't cause any issues with compliant client
implementation

> rob
> 
> > 
> > Are these relevant/serious ? Can they be mitigated ?
> > 
> > 
> > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcrit...@redhat.com
> > <mailto:rcrit...@redhat.com>> wrote:
> > 
> > Prasun Gera wrote:
> > > Yes, that's what I was planning to do. i.e. Convert cipher names from
> > > SSL to NSS. I wasn't sure about the other settings though. Is there an
> > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are 
> > there
> > > equivalent configs for HSTS on the mozilla page? Does NSS allow using
> > > generated DH parameters instead of standard ones ? For SSL, the
> > > suggested modification to the config is 'SSLOpenSSLConfCmd 
> > DHParameters
> > > "{path to dhparams.pem}"' after generating the params.
> > 
> > NSS does not let the user specify cipher order. It uses its own internal
> > sorting from strongest to weakest.
> > 
> > HSTS is a header and not dependent upon SSL provider.
> > 
> > mod_nss doesn't support DH ciphers.
> > 
> > rob
> > 
> > >
> > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <ftwee...@redhat.com 
> > <mailto:ftwee...@redhat.com>
> > > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>> wrote:
> > >
> > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> > > > Thanks for the ticket information. I would still be interested 
> > in
> > > > configuring mod_nss properly (irrespective of whether the certs 
> > are ipa
> > > > generated or 3rd party). These are the worrying notes from 
> > ssllabs test:
> > > >
> > > > The server supports only older protocols, but not the current 
> > best TLS 1.2.
> > > > Grade capped to C.
> > > > This server accepts the RC4 cipher, which is weak. Grade capped 
> > to B.
> > > > The server does not support Forward Secrecy with the reference 
> > browsers.
> > > >
> > > Use the "Modern" cipher suite[1] recommended by Mozilla as a
> > > starting point.  See also the "Cipher names correspondence table" 
> > on
> > > the same page for translating it to cipher names understood by NSS
> > > to construct a valid setting for the `NSSCipherSuite' directive.
> > >
> > > [1]
> > > 
> > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
> > >
> > > Cheers,
> > > Fraser
> > >
> > > >
> > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale
> > > <ftwee...@redhat.com <mailto:ftwee...@redhat.com>
> > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>> wrote:
> > > >
> > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote:
> > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui
> > accessible
> > > publicly.
> > > > > I'm
> > > > > > using a stock configuration which uses the certs signed by
> > > ipa's CA for
> > > > > the
> > > > > > webui. This is mostly for convenience since it ma

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote:
> I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. I'm
> using a stock configuration which uses the certs signed by ipa's CA for the
> webui. This is mostly for convenience since it manages renewals seamlessly.
> This, however, requires users to add the CA as trusted to their browsers. A
> promising alternative to this is https://letsencrypt.org/, which issues
> browser trusted certs, and will manage auto renewals too (in the future).
> As a feature request, it would be nice to have closer integration between
> ipa and the letsencrypt client which would make managing certs simple. I'm
> about to set this up manually right now using the external ssl certs guide.
> 
Let's Encrypt is on our radar.  I like the idea of being able to
install FreeIPA with publicly-trusted certs for HTTP and LDAP from
the beginning.  This would require some work in ipa-server-install
in addition to certmonger support and a good, stable Let's Encrypt /
ACME client implementation for Apache on Fedora.

Installing publicly-trusted HTTP / LDAP certs is a common activity
so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431

Cheers,
Fraser

> Secondly, since the webui uses mod_nss, how would one set it up to prefer
> security over compatibility with older clients ? The vast majority of
> documentation online (for eg.
> https://mozilla.github.io/server-side-tls/ssl-config-generator/) is about
> mod_ssl and I think the configuration doesn't transfer directly to mod_nss.
> Since this is the only web facing component, I would like to set it up to
> use stringent requirements. Right now, a test on
> https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html
> identifies
> several issues. Since these things are not really my area of expertise, I
> would like some documentation regarding this. Also, would manually
> modifying any of the config files be overwritten by a yum update ?

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA dogtag pkinit

[Fraser Tweedale]

On Fri, Oct 30, 2015 at 03:02:56PM +0100, Sumit Bose wrote:
> On Thu, Oct 29, 2015 at 03:55:45PM +0100, Jean 'clark' EYMERIT wrote:
> > Hello,
> > 
> > I search a way to use pkinit
> > (http://web.mit.edu/kerberos/krb5-devel/doc/admin/pkinit.html) with
> > FreeIPA (even without dogtag).
> > 
> > Can someone give me a howto for this ?
> 
> I can follow the steps described in the MIT pkinit instructions from
> above. Besides creating the needed certificates you only have to modify
> krb5.conf on the IPA server and client. The kadmin steps are not needed
> here because pre-authentication is already requeired for all IPA users.
> 
> > 
> > On the official documentation and the ML archive, I only find some
> > references about the disabled feature because of the dogtag incompatibility.
> 
> yes, this was mainly done because there are special requirements on the
> certificates as can been seen from the MIT document, which where hard to
> meet to at the time.
> 
> With the latest version of FreeIPA we now have certificate profiles
> which should allow an automatic pkinit setup in future versions of IPA.
> My plan is to check what is needed here during the next weeks.
> 
We support the Krb5PrincipalName OtherName SAN already, even in the
default profile**.  It must be included in the PKCS #10 CSR (per
instructions at MIT page above) and values are validated by FreeIPA
before passing to Dogtag.

** Key Usage / Extended Key Usage would probably not be appropriate
   for user certs, though.

There's a ticket for "CSR templates"[1] to make doing this sort of
thing easier.  Eventually I would like to have profiles that don't
need any special info in the CSR but just read data from the
directory.

[1] https://fedorahosted.org/freeipa/ticket/4899

Cheers,
Fraser

> HTH
> 
> bye,
> Sumit
> 
> > 
> > Some links after my search :
> > https://github.com/encukou/freeipa/blob/master/ipalib/plugins/pkinit.py
> > https://www.redhat.com/archives/freeipa-devel/2010-November/msg00348.html
> > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00906.html
> > 
> > The only intersting thing I know, it's this doc to create FreeIPA server
> > without Dogtag :
> > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/creating-server.html
> > 
> > Thanks you in advance for any information on the subject.
> > 
> > -- 
> > Jean Eymerit
> > 
> > 
> > -- 
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project