Re: [Freeipa-users] Where should the CA Location

[Florence Blanc-Renaud]

Hi

Disclaimer: I'm new on this mailing list but willing to share experience :)

Did you use "ipa-cacert-manage install -t C,," to install your external 
CA certificate? This command copies the certificate in 
cn=certificates,cn=ipa,cn=etc,dc=xxx


After this, you can use ipa-certupdate which will put the CA cert in all 
the needed NSS databases and update the nickname where needed.


Flo.

On 06/23/2016 04:54 AM, barry...@gmail.com wrote:

Hi :

I renew External CA cert below ...seem server-cert ok.

But ca CERT FAIL..
I ALREADY PASTE ON
/etc/httpd/alias
/etc/dirsrv/slapd-PKI-IPA
/etc/dirsv/slapd-ABX-com
/var/lib/pki-ca/alias 's CA conf

any idea?

 ABX-COM...[23/Jun/2016:10:42:32 +0800] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert
Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable
Runtime error -8179 - Peer's Certificate issuer is not recognized.)





--
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 / Change SSL Certificate for Web Server

[Florence Blanc-Renaud]

On 07/22/2016 05:08 AM, Devin Acosta wrote:


I have just installed a newly created FreeIPA server running CentOS 7.2.
I have a (wildcard) SSL Certificate that I want to use for the FreeIPA
Web Management GUI. I tried to follow the directions listed here at the
URL
of https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
however when I run those steps I get the error message:

ipa-server-certinstall -w -d star.linuxstack.cloud.key
star.linuxstack.cloud.crt
Directory Manager password:

Enter private key unlock password:

org.fedorahosted.certmonger.duplicate: Certificate at same location is
already used by request with nickname "20160722021526".

Any ideas? It seems like I need to somehow just get the one installed by
default replaced. I don't see any information on how to just replace it?





Hi Devin,

you may be hitting issue 4785 [1]. When ipa-server-certinstall is run, 
it does not stop tracking the previous server certificate and fails to 
start tracking the new cert.


As a side note, with -w -d you are replacing both the directory server 
certificate and the Web Management GUI certificate. If you only want to 
replace the web cert, you can drop the -d option.


Flo.

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

--
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-server-install --external-cert-file and exporting dogtag certificates

[Florence Blanc-Renaud]

On 08/02/2016 04:52 AM, Richard Harmonson wrote:

On Mon, Aug 1, 2016 at 10:15 AM, Petr Vobornik > wrote:

On 07/31/2016 07:45 AM, Richard Harmonson wrote:
> I having challenges resuming ipa-server-install --external-ca. I
am reasonably
> confident I am not providing the right certificate and/or format
from my
> off-line root CA using 389 and Dogtag.
>
> Does anyone have instructions on how to accomplish the task of
exporting the
> correct certificates in the expected format?
>
> Thank you.
>

The IPA procedure with prerequisites is described at

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca

Or are you rather asking for specific PKI instructions?

e.g.
*

http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request

*

http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
--
Petr Vobornik


I read the suggested document, previously, but its an excellent shared
reference for this discussion.

I have successfully submitted and approved the csr. Dogtag provides a
web UI which provides a Base 64 encoded certificate or Base 64 encoded
certificate with CA certificate chain in pkcs7 format.

For the servercert2010601.pem (the signed CSR request signing CA
certificate 0x9) referenced in the article, do I  copy and paste
(-BEGIN .. END-) the base 64 (not pkcs7) to a file using *.pem
then submit using one of the two --external-cert-file?

For the cacert.pem (the Root CA signing certificate 0x1) referenced in
the article, do I copy and paste the base 64 with ca in pkcs7 format to
a file using *.pkcs7 (or pem or does it matter?) then submit using the
second --external-cert-file?

Your guidance is much appreciated.



Hi Richard,

I tested the following steps to install FreeIPA with a certificate 
signed by an external Dogtag instance:


1- IPA installation on host ipaserver with:
ipaserver$ ipa-server-install [options] --external-ca

This step produces the Certificate Signing Request /root/ipa.csr that 
must be provided to the Dogtag server.


2- On the Dogtag machine, configure Dogtag client authentication (to be 
able to use the command-line):


dogtagsrv$ pki -c password client-init

This step creates a NSSDB in ~/.dogtag/nssdb where the certificates for 
client->dogtag server authentication will be stored.


dogtagsrv$ pk12util -i /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -d 
/root/.dogtag/nssdb/


This step imports the caadmin certificate that was created during Dogtag 
installation into the client NSSDB. The client will be able to 
authenticate as "caadmin" when using Dogtag CLI. Please note the 
certicate nickname that can be found using


dogtagsrv$ certutil -L -d ~/.dogtag/nssdb/
[...]
PKI Administrator for  u,u,u

3- On the Dogtag machine, submit the CSR and approve:
dogtagsrv$ pki ca-cert-request-submit --profile caCACert --request-type 
pkcs10 --csr-file  /path/to/ipa.csr


This step submits the csr to Dogtag, using the caCACert profile in order 
to produce a Certificate that can be used for a Certificate Authority. 
Note the Request ID in the output as it will be used in the next command 
to approve the CSR and produce the cert:


dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for 
"  cert-request-review  --action approve


4- On the Dogtag machine, export the certificate and the dogtag CA cert:

dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator for 
"  cert-show 7 --encoded --output  ipa.cert

dogtagsrv$ pki ca-cert-show 1 --encoded --output dogtagca.cert

5- Resume ipa server installation with

ipaserver$ ipa-server-install --external-cert-file=ipa.cert 
--external-cert-file=dogtagca.cert


With those steps, I was able to install FreeIPA server with a 3rd-party 
signed Certificate Authority. Please let me known if you have issues 
with those instructions,


Flo.

--
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-server-install --external-cert-file and exporting dogtag certificates

[Florence Blanc-Renaud]

On 08/03/2016 07:54 PM, Richard Harmonson wrote:

On Wed, Aug 3, 2016 at 12:49 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 08/02/2016 04:52 AM, Richard Harmonson wrote:

On Mon, Aug 1, 2016 at 10:15 AM, Petr Vobornik
<pvobo...@redhat.com <mailto:pvobo...@redhat.com>
<mailto:pvobo...@redhat.com <mailto:pvobo...@redhat.com>>> wrote:

On 07/31/2016 07:45 AM, Richard Harmonson wrote:
> I having challenges resuming ipa-server-install
--external-ca. I
am reasonably
> confident I am not providing the right certificate and/or
format
from my
> off-line root CA using 389 and Dogtag.
>
> Does anyone have instructions on how to accomplish the task of
exporting the
> correct certificates in the expected format?
>
> Thank you.
>

The IPA procedure with prerequisites is described at


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca

Or are you rather asking for specific PKI instructions?

e.g.
*


http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request

*


http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
--
Petr Vobornik


I read the suggested document, previously, but its an excellent
shared
reference for this discussion.

I have successfully submitted and approved the csr. Dogtag
provides a
web UI which provides a Base 64 encoded certificate or Base 64
encoded
certificate with CA certificate chain in pkcs7 format.

For the servercert2010601.pem (the signed CSR request signing CA
certificate 0x9) referenced in the article, do I  copy and paste
(-BEGIN .. END-) the base 64 (not pkcs7) to a file using
*.pem
then submit using one of the two --external-cert-file?

For the cacert.pem (the Root CA signing certificate 0x1)
referenced in
the article, do I copy and paste the base 64 with ca in pkcs7
format to
a file using *.pkcs7 (or pem or does it matter?) then submit
using the
second --external-cert-file?

Your guidance is much appreciated.


Hi Richard,

I tested the following steps to install FreeIPA with a certificate
signed by an external Dogtag instance:

1- IPA installation on host ipaserver with:
ipaserver$ ipa-server-install [options] --external-ca

This step produces the Certificate Signing Request /root/ipa.csr
that must be provided to the Dogtag server.

2- On the Dogtag machine, configure Dogtag client authentication (to
be able to use the command-line):

dogtagsrv$ pki -c password client-init

This step creates a NSSDB in ~/.dogtag/nssdb where the certificates
for client->dogtag server authentication will be stored.

dogtagsrv$ pk12util -i /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -d
/root/.dogtag/nssdb/

This step imports the caadmin certificate that was created during
Dogtag installation into the client NSSDB. The client will be able
to authenticate as "caadmin" when using Dogtag CLI. Please note the
certicate nickname that can be found using

dogtagsrv$ certutil -L -d ~/.dogtag/nssdb/
[...]
PKI Administrator for  u,u,u

3- On the Dogtag machine, submit the CSR and approve:
dogtagsrv$ pki ca-cert-request-submit --profile caCACert
--request-type pkcs10 --csr-file  /path/to/ipa.csr

This step submits the csr to Dogtag, using the caCACert profile in
order to produce a Certificate that can be used for a Certificate
Authority. Note the Request ID in the output as it will be used in
the next command to approve the CSR and produce the cert:

dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator
for "  cert-request-review  --action approve

4- On the Dogtag machine, export the certificate and the dogtag CA cert:

dogtagsrv$ pki -c password -d ~/.dogtag/nssdb/ -n "PKI Administrator
for "  cert-show 7 --encoded --output  ipa.cert
dogtagsrv$ pki ca-cert-show 1 --encoded --output dogtagca.cert

5- Resume ipa server installation with

ipaserver$ ipa-server-install --external-cert-file=ipa.cert
--external-cert-file=dogtagca.cert

With those steps, I was able to install FreeIPA server with a
3rd-party signed Certificate Authority. Please let me known if you
have issues with those instructions,

Flo.

Re: [Freeipa-users] updating certificates

[Florence Blanc-Renaud]

Hi Josh,

depending on your IPA version, you may consider using 
ipa-server-certinstall and ipa-certupdate.


ipa-server-certinstall can be used to install a new certificate for 
Apache/LDAP servers, and ipa-certupdate to update the NSS DBs with the 
CA certificates found in the LDAP server.


Flo.

On 08/09/2016 05:48 PM, Josh wrote:

Rob,

One must also update /etc/ipa/nssdb the same way, otherwise ipa cli tool
gets SEC_ERROR_UNTRUSTED_ISSUER !

It would be nice to have an IPA tool  to update all certificates in all
required places.

Also, why would I need to add CA that already in system ca-trust to the
private IPA nssdb?

Josh.


On 06/28/2016 10:50 AM, Rob Crittenden wrote:

j...@use.startmail.com wrote:

Greetings,

About a year ago I installed my freeipa server with certificates from
startssl using command line options --dirsrv-cert-file --http-cert-file
etc.
The certificate is about to expire, what is the proper way to update it
in all places?


It depends on whether you kept the original CSR or not. If you kept
the original CSR and are just renewing the certificate(s) then when
you get the new one, use certutil to add the updated cert to the
appropriate NSS database like:

# certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i
/path/to/new.crt

If you need to generate a new CSR then you can use
ipa-server-certinstall to install the updated key and crt files.

In either case probably worth backing up /etc/httpd/alias/*.db and
/etc/dirsrv/slapd-INSTANCE/*.db.

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] regenerate certificate

[Florence Blanc-Renaud]

On 07/20/2016 10:04 PM, mohammad sereshki wrote:

hi
I check my IPA server which is version ipa-server-3.0.0-25 , command
"ipa-get-cert list" show, my certificate will be expired in next 20 days,
I do not know how to regenerate them
but command "getcert list" shows epirtion certificates are related just
to "CA:IPA" and certificate " CA: dogtag-ipa-renew-agent" ,  has enough
time .
would you please help me to know how to regenerate CA:IPA certificates?

Best Regards





Hi Mohammad,

the certificates issued by IPA CA are normally tracked by certmonger and 
automatically renewed when they are near their expiration date. To make 
sure that your certificates are tracked, you can issue

$ ipa-getcert list
and check the "status:" field for each certificate. It should display 
"MONITORING".


If you want to manually renew them, you must note their request ID and 
use the command

$ ipa-getcert resubmit -i $REQUEST_ID

Hope this helps,
Flo.

--
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] A question related the passwords in the ldap

[Florence Blanc-Renaud]

Hi Bahan,

the user passwords stored in LDAP follow the password policy configured 
in the LDAP server, which defines password syntax requirements as well 
as the password encryption algorithm. You can find more information in 
RedHat Directory Server Administration Guide, in the section Managing 
the Password Policy:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy

By default, the password storage scheme is SSHA. This means that when a 
user entry is created with a password, the directory server encrypts the 
password using SSHA before actually storing it in the user entry.


I hope this answers your question,
Flo.

On 07/05/2016 09:40 AM, bahan w wrote:

Hello !

I'm running ipa 3.0.0.47 and I have a question related to the password
stored in the ldap.

I was wondering if the users password were natively encrypted ?
if yes, do you know by which mechanism ?

Thank you in advance for your help.

BR.

Bahan




--
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] Third Party Certificate

[Florence Blanc-Renaud]

On 08/02/2016 03:17 PM, Ian Harding wrote:

Hello!

I have been using FreeIPA for a while in our network with 6 replicas and
it's been working great.  I seem to have made a wee mistake though and
I'd appreciate some help.

I did this:

https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

on one server because I had a new cert for our internal domain and I
thought it might be nice to use the same cert for all our internal web
services.

It worked fine but now when I'm on that server I get
SEC_ERROR_UNTRUSTED_ISSUER when I run ipa commands.  Is there any way I
can roll this back, or make it work as is?

Thanks!

-Ian


Hi Ian,

if the certificate that you installed was issued by a CA not known by 
IPA (let's call him the issuer), then you need to add this issuer cert 
first using:

ipa-cacert-manage install  -n nickname -t C,,
kinit admin
ipa-certupdate

You can check that the issuer cert is properly installed in 
/etc/httpd/alias and /etc/ipa/nssdb with:

certutil -L -d /etc/httpd/alias
certutil -L -d /etc/ipa/nssdb
where it should appear with C,, flags

Hope this helps,
Flo.

--
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 reisnatll the ca or the dogtag system

[Florence Blanc-Renaud]

Hi,

the message "LDAP Server Down" seems to indicate that the LDAP server is 
not started. You can restart it using:

systemctl restart dirsrv@REALM.service

Flo.

On 06/29/2016 03:58 AM, Barry wrote:

Hi:

Errors occur ...cert ni problem ..seem ca error and cannot tract cert.
thx

ipa-replica-prepare c03.abc.com  --ip-address
192.168.1.73
Directory Manager (existing master) password:

preparation of replica failed: cannot connect to
u'ldapi://%2fvar%2frun%2fslapd-WISERS-COM.socket': LDAP Server Down
cannot connect to u'ldapi://%2fvar%2frun%2fslapd-ABC.COM.socket': LDAP
Server Down
  File "/usr/sbin/ipa-replica-prepare", line 490, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 274, in main
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=dirman_password)

  File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in
connect
conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py",
line 846, in create_connection
self.handle_errors(e)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py",
line 736, in handle_errors
error=u'LDAP Server Down')

[root@central ~]# ipa-replica-prepare central03.wisers.com
 --ip-address 192.168.1.73
Directory Manager (existing master) password:

preparation of replica failed: cannot connect to
u'ldapi://%2fvar%2frun%2fslapd-ABC.COM.socket': LDAP Server Down
cannot connect to u'ldapi://%2fvar%2frun%2fslapd-ABC-COM.socket': LDAP
Server Down
  File "/usr/sbin/ipa-replica-prepare", line 490, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 274, in main
conn.connect(bind_dn=DN(('cn', 'directory manager')),
bind_pw=dirman_password)

  File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in
connect
conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py",
line 846, in create_connection
self.handle_errors(e)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py",
line 736, in handle_errors
error=u'LDAP Server Down')





--
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 should the CA Location

[Florence Blanc-Renaud]

Hi,

it looks like the NSS db for slapd-ABX-com does not contain the full 
cert chain. You can run certutil -L -d /etc/dirsv/slapd-ABX-com and 
check if there is a certificate for your issuer, and if it has the C,, 
flags at least.


For instance, in my setup I am using ca2/server certificate for slapd, 
and this certificate was issued by ca2:

$ certutil -L -d /etc/dirsrv/slapd-xxx

Certificate Nickname Trust 
Attributes


SSL,S/MIME,JAR/XPI

ca2/server   u,u,u
ca2  C,,

Flo.

On 06/29/2016 12:26 PM, barry...@gmail.com wrote:

It is 3.0 version cannot use those commands.

2016-06-25 2:06 GMT+08:00 Florence Blanc-Renaud <fren...@redhat.com
<mailto:fren...@redhat.com>>:

Hi

Disclaimer: I'm new on this mailing list but willing to share
experience :)

Did you use "ipa-cacert-manage install -t C,," to install your
external CA certificate? This command copies the certificate in
cn=certificates,cn=ipa,cn=etc,dc=xxx

After this, you can use ipa-certupdate which will put the CA cert in
all the needed NSS databases and update the nickname where needed.

Flo.


On 06/23/2016 04:54 AM, barry...@gmail.com
<mailto:barry...@gmail.com> wrote:

Hi :

I renew External CA cert below ...seem server-cert ok.

But ca CERT FAIL..
I ALREADY PASTE ON
/etc/httpd/alias
/etc/dirsrv/slapd-PKI-IPA
/etc/dirsv/slapd-ABX-com
/var/lib/pki-ca/alias 's CA conf

any idea?

 ABX-COM...[23/Jun/2016:10:42:32 +0800] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert
Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape
Portable
Runtime error -8179 - Peer's Certificate issuer is not recognized.)




--
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] Backend & UI plugin update for 4.4.x

[Florence Blanc-Renaud]

On 02/01/2017 05:47 PM, Steve Huston wrote:

Would it be better to file this as a new bug, or reopen 4291?


Hi,

we are already aware of the problem and working on a fix (please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and 
https://fedorahosted.org/freeipa/ticket/6575).


HTH,
Flo.


On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston
 wrote:

Seems like this is to blame:  https://fedorahosted.org/freeipa/ticket/4291

The checkin says, "Installation in pure IPv6 environment failed
because pki-tomcat tried to use
IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4
fixes this issue."  However it would seem that in a pure IPv4
environment, this is causing tomcat to fail to load.

On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston
 wrote:

What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml?





Doesn't work so well on a host without IPv6 turned on...

Jan 31 14:26:59 ipa server: PKIListener:
org.apache.catalina.core.StandardServer[before_init]
Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point
associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"]
Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family
unavailable

On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston
 wrote:

Stranger, I did an install on a different VM with the CentOS 7 minimal
ISO, then installed ipa-server and enough things to get X11 and
Firefox, ran ipa-server-install and it worked fine.  I tested with
Firefox (and Safari) against my failing installation and it still
fails.  So there's something else different that's causing it to
break.  Will continue investigating, but if someone knows why the UI
would break this way it would be helpful to know where to look!

On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston
 wrote:

Just did it again with the same result.  Reinstalled the machine, then
did a 'yum install ipa-server python2-ipaserver httpd' which pulled in
version 4.4.0-14.el7_3.4 and a bunch of other packages.  Next was the
ipa-server-install as I used before, only without --mkhomedir this
time.  After entering the passwords for directory administrator and
the admin user, I then logged in to the web interface, immediately
clicked "add" and added a user 'foobar'.  When I clicked "add and
edit" and was brought to the user information page, it looks like this
at the bottom:

https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0

I then entered an employee number of '0001' just to give something to
save, and clicked save.  The screen now shows this (I've clicked the
drop-down on the manager field so the choices are visible):

https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0

Holding shift and clicking reload, the page now looks like this (the
employee number field is also blank again):

https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0

Since we do run a repackaged distribution here (Springdale Linux), I
just unpacked ipa-server-common from our repository with the above
version, and 
http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm,
and 'diff' found zero differences between them.  Unlikely, but I
wanted to rule out a packaging error causing the problem.

On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston
 wrote:

No, that should be all of the major changes; the puppet module that
installs things only puts the two plugin files in their respective
places.  The client part of the IPA module makes changes to have the
machine join the domain and whatnot, but those shouldn't affect the
webui.

I do modify the schema by adding some attribute types for Puppet,
namely puppetClass, parentNode, environment, puppetVar, and the object
class puppetClient.  That's basically right from one of the Puppet
webpages and also worked in the past - and is one of the things the
python plugin does, add the appropriate objectclass to host entries if
puppetVar is added to a host entry.

My steps to install:
* ipa-server-install --realm= --domain= --mkhomedir
--hostname= --no-host-dns
* ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W
  < paste puppet schema changes>
  < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a
service account used by puppet for adding hosts to IPA >
* login to web UI
* * Change home directory base, default shell, default SELinux user
* * Add SELinux user map for staff/sysadmin users
* * Add "user adder" permission/privilege/role for users who will be
able to create stageusers

That's about as far as I got before I realized some of the plugin
pieces weren't working, and then fixed the python plugin followed by
working on the UI plugin and finding this problem.  I'll go wipe and
reinstall the system again and walk through the steps, but test 

Re: [Freeipa-users] FreeIPA Help

[Florence Blanc-Renaud]

On 02/22/2017 04:41 AM, Daniel Schimpfoessl wrote:

Is there a way for me to export my data (users, groups, ...), rebuild
the server and import the data again?

Daniel


Hi Daniel,

please keep the mailing list in CC as the content may also benefit other 
users with similar issues.


Does anyone have suggestions in order to fix the broken CA?
Thanks,
Flo


2017-02-09 12:33 GMT-06:00 Florence Renaud >:

Hi Daniel,

You can try to contact the mailing list for Dogtag (the certificate
system): pki-us...@redhat.com 

If possible, state which certificates were renewed (the CA cert, or
the one used by Dogtag server/http server/ldap server), and how
(automatically by certmonger when approaching the expiration or
manually, then provide the command used).

A customer recently hit an issue when renewing the CA cert, where
the subject name in the renewed cert was encoded differently and
thus not recognised as the same identity even though using the same
private key.
https://fedorahosted.org/pki/ticket/2587


Flo.



Envoyé de mon iPad
Le 8 févr. 2017 à 19:48, Daniel Schimpfoessl
> a écrit :


Flo,

can you help me understand how to best get further help?
https://www.redhat.com/archives/freeipa-users/2017-January/msg00422.html


Thanks,

Daniel





--
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] Cannot install 3rd party certificate

[Florence Blanc-Renaud]

On 02/16/2017 09:55 PM, Matt . wrote:

Hi Flo! (if I may call you like that, saves some characters in typing
but with this extra line it doesn't anymore :))

This works perfectly, thank you very much.


Hi Matt,

glad I could help. What did you do differently that could explain the 
failure, though? Maybe the cert installation needs some hardening.


Flo.

No questions further actually :)

Cheers,

Matt

2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:

On 02/15/2017 05:40 PM, Matt . wrote:


Hi,

Is there any update on this ? I need to install 3 other instances but
I would like to know upfront if it might be a bug.


Hi Matt,

I was not able to reproduce your issue. Here were my steps:

Install FreeIPA with self-signed cert:
ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD

The certificate chain is ca1 -> subca -> server.
Install the root CA:
kinit admin
ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem
ipa-certupdate

Install the subca:
ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem
ipa-certupdate

Install the server cert:
ipa-server-certinstall -d -w server.pem key.pem

ipa-certupdate basically retrieves the certificates from LDAP (below
cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias but
I don't remember it removing certs.

Can you check the content of your LDAP server?
kinit admin
ldapsearch -h `hostname` -p 389 -Y GSSAPI -b
cn=certificates,cn=ipa,cn=etc,$BASEDN

It should contain one entry for each CA that you added.

Flo.


Thanks,

Matt

2017-02-14 17:59 GMT+01:00 Matt . <yamakasi@gmail.com>:


Hi Florance,

Sure I can, here you go:

Fedora 24
Freeipa VERSION: 4.4.2, API_VERSION: 2.215

I installed this server as self-signed CA

Cheers,

Matt




2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:


On 02/14/2017 05:43 PM, Matt . wrote:



Hi Florance,

Thanks for your update, good to see some good into about it. For
Comodo I have install all these:

AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt

 Where COMODORSADomainValidationSecureServerCA.crt is not needed as
far as I know but the same issues still exist, the Server-Cert is
removed again on ipa-certupdate and fails.

I have tried this with setenforce 0


Hi Matt,

can you provide more info in order to reproduce the issue?
- which OS are you using
- IPA version
- how did you install ipa server (CA-less or with self-signed CA or with
externally-signed CA?)

Thanks,
Flo.



Cheers,

Matt

2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:



On 02/14/2017 02:54 PM, Matt . wrote:




Certs are valid, I will check what you mentioned.

I'm also no fan of bundles, more the seperate files but this doesn't
seem to work always. At least for the CAroot a bundle was required.


Hi Matt,

if your certificate was provided by an intermediate CA, you need to
add
each
CA before running ipa-server-certinstall (start from the top-level CA
with
ipa-cacert-manage install, then run ipa-certupdate, then the
intermediate
CA
with ipa-cacert-manage install, then ipa-certupdate etc...)

There is also a known issue with ipa-certupdate and SELinux in
enforcing
mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024).

Flo.



Matt

2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI]
<dsulliv...@bsd.uchicago.edu>:




Have you validated the cert (and dumped the contents) from the
command
line using the openssl tools?  I’ve seen the message you are seeing
before,
for some reason I seem to remember that it has to do with either a
missing
or an extra - at either the -BEGIN CERTIFICATE or -END
CERTIFICATE (an error from copy and pasting and not copying the
actual
file).

I’ve never used certupdate so if what is described above doesn’t
help
somebody else will have to chime in.

Dan


On Feb 14, 2017, at 2:18 AM, Matt . <yamakasi@gmail.com> wrote:

Hi Dan,

Ues i have tried that and I get the message that it misses the full
chain for the certificate.

My issue is more, why is the Server-Cert being removed on a
certupdate
?

Cheers,

Matt

2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI]
<dsulliv...@bsd.uchicago.edu>:




Is the chain in mydomain_com_bundle.crt?  Have you tried it with
the
cert only (disclaimer: I’ve never done this).

Dan


On Feb 13, 2017, at 4:08 PM, Matt . <yamakasi@gmail.com>
wrote:

Hi Guys,

I'm trying to install a 3rd party certificate using:




http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA

When I run the install command for the certificate itself:

]# ipa-server-certinstall -w -d mydomain_com.key
mydomain_com_bundle.crt
Directory Manager password:

Enter private key unlock password:

list index out of range
The ipa-server-certinstall command failed.


If I do a #ipa-certupdate the Server-Cert is removed from
/etc/httpd/alias and the install fails b

Re: [Freeipa-users] Cannot install 3rd party certificate

[Florence Blanc-Renaud]

On 02/20/2017 04:09 PM, Matt . wrote:

Hi Rob,

Yes it does, I understood that there was some reason the duplicate
might exist, but I wonder more why does the RootCA show up when I
removed it and comes back after adding the two intermediates ?


Hi Matt,

when ipa-cacert-manage install is run, it adds an LDAP entry for the new 
CA certificate below cn=certificates,cn=ipa,cn=etc,$BASEDN.
When ipa-certupdate is run, it adds all the certificates found in 
cn=certificates,cn=ipa,cn=etc,$BASEDN to /etc/httpd/alias.
So even if you remove one certificate from /etc/httpd/alias, the next 
ipa-certupdate command will re-add this CA cert if it is still present 
in LDAP.


Hope this clarifies,
Flo.



Thanks

Matt


2017-02-20 15:20 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:

Matt . wrote:

Hi,

The install seems to be OK this way, but I'm still confused about the
duplicated and the RootCA.


What does this show?

#3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA

I'm guessing it will show two certs with different serial numbers, which
means this is a-ok.

rob



2017-02-18 14:47 GMT+01:00 Matt . <yamakasi@gmail.com>:

Hi Florance,


I'm actually stil investigating this as the following occurs.

I have removed all unneeded certs and installed the 2 intermediates
for Comodo and did an ipa-certupdate which results in this:

#certutil -L -d /etc/httpd/alias

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
Limited,L=Salford,ST=Greater Manchester,C=GB C,,
AddTrustExternalCARoot   C,,
ipaCert  u,u,u
COMODORSAAddTrustCA  C,,
COMODORSAAddTrustCA  C,,
IPA.MYDOMAIN.TLD IPA CA CT,C,C


I'm curious why the COMODORSAAddTrustCA is there twice, if I remove
both and start over they are duplicated again. Also the
AddTrustExternalCARoot comes back again even when this was not
installed anymore as it's not needed.

I'm able to install my cert after the update:


#certutil -L -d /etc/httpd/alias

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
Limited,L=Salford,ST=Greater Manchester,C=GB C,,
AddTrustExternalCARoot   C,,
ipaCert  u,u,u
COMODORSAAddTrustCA  C,,
COMODORSAAddTrustCA  C,,
IPA.MYDOMAIN.TLD IPA CA CT,C,C
CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated u,u,u



Now this works great for the WebGui which uses the right Certificate
for the ssl connection but ldaps on port 636 seems to use:

CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
Limited,L=Salford,ST=Greater Manchester,C=GB


Do you have any clue about this ?

I'm also curious about what IPA syncs between all hosts, it seems to
be only the Intermediate certs and not the install domains
certificate, this needs to be installed manually after a local
#ipa-certupdate on each node ?

I hope you can clearify this out.


Thanks,

Matt


2017-02-17 0:15 GMT+01:00 Matt . <yamakasi@gmail.com>:

Hi Flo,

Sure I can, I will look through the steps closely tomorrow and will
create some lineup here.

Cheers,

Matt

2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:

On 02/16/2017 09:55 PM, Matt . wrote:


Hi Flo! (if I may call you like that, saves some characters in typing
but with this extra line it doesn't anymore :))

This works perfectly, thank you very much.


Hi Matt,

glad I could help. What did you do differently that could explain the
failure, though? Maybe the cert installation needs some hardening.

Flo.


No questions further actually :)

Cheers,

Matt

2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud <f...@redhat.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

Re: [Freeipa-users] can't add replica: failed to start the directory server

[Florence Blanc-Renaud]

On 02/17/2017 10:36 AM, Tiemen Ruiten wrote:

I went through that bugreport, particularly this section...

OK, I think I found the error. On the logs I get something like this
*before* the failing dirsrv restart:

2017-01-14T03:41:28Z DEBUG   [27/44]: retrieving DS Certificate
2017-01-14T03:41:28Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'
2017-01-14T03:41:28Z DEBUG Starting external process
2017-01-14T03:41:28Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ 
-L -n EXAMPLE.COM  IPA CA -a
2017-01-14T03:41:28Z DEBUG Process finished, return code=255
2017-01-14T03:41:28Z DEBUG stdout=
2017-01-14T03:41:28Z DEBUG stderr=certutil: Could not find cert: EXAMPLE.COM 
 IPA CA
: PR_FILE_NOT_FOUND_ERROR: File not found



Hi,

this error shows that the server certificate for the LDAP server is not 
present in the NSS database. I am pretty sure that if you run

$ getcert list -d /etc/dirsrv/slapd-DOMAIN
you will get an error like this one:
status: CA_UNREACHABLE
	ca-error: Server at https://ipa.EXAMPLE.COM/ipa/xml failed request, 
will retry: 4301 (RPC failed at server.  Certificate operation cannot be 
completed: Unable to communicate with CMS (503)).


Make sure that the file /etc/pki/pki-tomcat/server.xml (on all the 
masters) defines the AJP connector like this:


and that the /etc/hosts file (on all the masters) properly defines 
localhost:
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 
localhost6.localdomain6

Then restart the PKI service on the masters:
systemctl stop pki-tomcatd@pki-tomcat.service

After this, you should be able to re-run ipa-replica-install without any 
problem.

HTH,
Flo.


So, when the process stopped, I run the command again:

# /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n EXAMPLE.COM 
 IPA CA -a
certutil: Could not find cert: EXAMPLE.COM 
: PR_FILE_NOT_FOUND_ERROR: File not found

and thought "wait... something is missing there":

# /usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L -n "EXAMPLE.COM 
 IPA CA" -a
-BEGIN CERTIFICATE-

-END CERTIFICATE-

So, could this be the problem?


...and indeed when I run

[tiemen@copernicum ipapython]$ sudo /usr/bin/certutil -d
/etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM
 IPA CA -a
[sudo] password for tiemen:
certutil: Could not find cert: IPA.RDMEDIA.COM 
: PR_FILE_NOT_FOUND_ERROR: File not found


and when I run

[tiemen@copernicum ipapython]$ sudo /usr/bin/certutil -d
/etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n "IPA.RDMEDIA.COM
 IPA CA" -a
-BEGIN CERTIFICATE-

-END CERTIFICATE-

valid certificate output. Where can I change this command to quote this
string?


On 16 February 2017 at 17:29, Jeff Goddard > wrote:

Might be another instance of this:
https://fedorahosted.org/freeipa/ticket/6613


Jeff

On Thu, Feb 16, 2017 at 11:21 AM, Tiemen Ruiten
> wrote:

Hello,

I'm trying to add a third replica to a FreeIPA 4.4 domain (level
1), but I'm getting this error:

[tiemen@copernicum ~]$ sudo ipa-replica-install -P admin -w
"XX" --mkhomedir --setup-dns --forwarder 8.8.8.8
--forwarder 8.8.4.4
Checking DNS forwarders, please wait ...
Run connection check to master
Connection check OK
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/44]: creating directory server user
  [2/44]: creating directory server instance
  [3/44]: updating configuration in dse.ldif
  [4/44]: restarting directory server
  [5/44]: adding default schema
  [6/44]: enabling memberof plugin
  [7/44]: enabling winsync plugin
  [8/44]: configuring replication version plugin
  [9/44]: enabling IPA enrollment plugin
  [10/44]: enabling ldapi
  [11/44]: configuring uniqueness plugin
  [12/44]: configuring uuid plugin
  [13/44]: configuring modrdn plugin
  [14/44]: configuring DNS plugin
  [15/44]: enabling entryUSN plugin
  [16/44]: configuring lockout plugin
  [17/44]: configuring topology plugin
  [18/44]: creating indices

Re: [Freeipa-users] Cannot install 3rd party certificate

[Florence Blanc-Renaud]

On 02/15/2017 05:40 PM, Matt . wrote:

Hi,

Is there any update on this ? I need to install 3 other instances but
I would like to know upfront if it might be a bug.


Hi Matt,

I was not able to reproduce your issue. Here were my steps:

Install FreeIPA with self-signed cert:
ipa-server-install -n $DOMAIN -r $REALM -p $PASSWORD -a $PASSWORD

The certificate chain is ca1 -> subca -> server.
Install the root CA:
kinit admin
ipa-cacert-manage -p $PASSWORD -n ca1 -t C,, install ca1.pem
ipa-certupdate

Install the subca:
ipa-cacert-manage -p $PASSWORD -n subca -t C,, install subca.pem
ipa-certupdate

Install the server cert:
ipa-server-certinstall -d -w server.pem key.pem

ipa-certupdate basically retrieves the certificates from LDAP (below 
cn=certificates,cn=ipa,cn=etc,$BASEDN) and puts them in /etc/httpd/alias 
but I don't remember it removing certs.


Can you check the content of your LDAP server?
kinit admin
ldapsearch -h `hostname` -p 389 -Y GSSAPI -b 
cn=certificates,cn=ipa,cn=etc,$BASEDN


It should contain one entry for each CA that you added.

Flo.

Thanks,

Matt

2017-02-14 17:59 GMT+01:00 Matt . <yamakasi@gmail.com>:

Hi Florance,

Sure I can, here you go:

Fedora 24
Freeipa VERSION: 4.4.2, API_VERSION: 2.215

I installed this server as self-signed CA

Cheers,

Matt




2017-02-14 17:54 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:

On 02/14/2017 05:43 PM, Matt . wrote:


Hi Florance,

Thanks for your update, good to see some good into about it. For
Comodo I have install all these:

AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt

 Where COMODORSADomainValidationSecureServerCA.crt is not needed as
far as I know but the same issues still exist, the Server-Cert is
removed again on ipa-certupdate and fails.

I have tried this with setenforce 0


Hi Matt,

can you provide more info in order to reproduce the issue?
- which OS are you using
- IPA version
- how did you install ipa server (CA-less or with self-signed CA or with
externally-signed CA?)

Thanks,
Flo.



Cheers,

Matt

2017-02-14 17:24 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com>:


On 02/14/2017 02:54 PM, Matt . wrote:



Certs are valid, I will check what you mentioned.

I'm also no fan of bundles, more the seperate files but this doesn't
seem to work always. At least for the CAroot a bundle was required.


Hi Matt,

if your certificate was provided by an intermediate CA, you need to add
each
CA before running ipa-server-certinstall (start from the top-level CA
with
ipa-cacert-manage install, then run ipa-certupdate, then the intermediate
CA
with ipa-cacert-manage install, then ipa-certupdate etc...)

There is also a known issue with ipa-certupdate and SELinux in enforcing
mode (https://bugzilla.redhat.com/show_bug.cgi?id=1349024).

Flo.



Matt

2017-02-14 14:51 GMT+01:00 Sullivan, Daniel [CRI]
<dsulliv...@bsd.uchicago.edu>:



Have you validated the cert (and dumped the contents) from the command
line using the openssl tools?  I’ve seen the message you are seeing
before,
for some reason I seem to remember that it has to do with either a
missing
or an extra - at either the -BEGIN CERTIFICATE or -END
CERTIFICATE (an error from copy and pasting and not copying the
actual
file).

I’ve never used certupdate so if what is described above doesn’t help
somebody else will have to chime in.

Dan


On Feb 14, 2017, at 2:18 AM, Matt . <yamakasi@gmail.com> wrote:

Hi Dan,

Ues i have tried that and I get the message that it misses the full
chain for the certificate.

My issue is more, why is the Server-Cert being removed on a certupdate
?

Cheers,

Matt

2017-02-14 2:18 GMT+01:00 Sullivan, Daniel [CRI]
<dsulliv...@bsd.uchicago.edu>:



Is the chain in mydomain_com_bundle.crt?  Have you tried it with the
cert only (disclaimer: I’ve never done this).

Dan


On Feb 13, 2017, at 4:08 PM, Matt . <yamakasi@gmail.com> wrote:

Hi Guys,

I'm trying to install a 3rd party certificate using:



http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_current_IPA

When I run the install command for the certificate itself:

]# ipa-server-certinstall -w -d mydomain_com.key
mydomain_com_bundle.crt
Directory Manager password:

Enter private key unlock password:

list index out of range
The ipa-server-certinstall command failed.


If I do a #ipa-certupdate the Server-Cert is removed from
/etc/httpd/alias and the install fails because of this.

What can I do to solve this ?

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] Switch certificates from external CA to internal

[Florence Blanc-Renaud]

On 01/12/2017 05:40 PM, Jeff Goddard wrote:

Thanks Flo,

My system is still in a bad state as I got this as a result of the command:

[root@id-management-1 ~]# ipa-cacert-manage renew --self-signed
Renewing CA certificate, please wait
Resubmitting certmonger request '20170101055025' timed out, please check
the request manually
The ipa-cacert-manage command failed.

The relevant output from getcert list was:
Request ID '20170101055025':
status: NEED_CSR_GEN_TOKEN
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM
<http://INTERNAL.EMERLYN.COM>
subject: CN=localhost
expires: 2037-01-01 06:28:46 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
pre-save command:
post-save command:
track: yes
auto-renew: yes

I took the step of stopping tracking on that cert which was a mistake
and now I'm having a hard time with the syntax of adding it back.


Hi Jeff,

You would need the following to start-tracking the cert:
1. get the internal PIN
# grep 'internal=' /etc/pki/pki-tomcat/password.conf

2. monitor the cert
# getcert start-tracking -d /etc/pki/pki-tomcat/alias -n 'caSigningCert 
cert-pki-ca' -P  -c dogtag-ipa-ca-renew-agent -B 
/usr/libexec/ipa/certmonger/stop_pkicad -C 
'/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'


HTH,
Flo.

Jeff







On Thu, Jan 12, 2017 at 10:46 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 01/12/2017 02:57 PM, Jeff Goddard wrote:

I've had issues with expired certificates. In the course of
troubleshooting I've somehow set the cas to external. Is there a
way I
can switch back?

[root@id-management-1 conf]# getcert list-cas
CA 'SelfSign':
is-default: no
ca-type: INTERNAL:SELF
next-serial-number: 01
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/ipa-submit
CA 'certmaster':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/certmaster-submit
CA 'dogtag-ipa-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
CA 'local':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/local-submit
CA 'dogtag-ipa-ca-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location:
/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit -vv

Thanks,

Jeff



Hi Jeff,

the following documentation explains how to change the certificate
chain from externally-signed to self-signed:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html>

HTH,
Flo.







--
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] 3rd party Certificate install

[Florence Blanc-Renaud]

Hi,

ipa-cacert-manage must be run as root but does not require any Kerberos 
ticket.


You can run the following command to check your directory manager password:
/usr/bin/ldapsearch -h localhost -p 389 -D "cn=directory manager" -w 
'#-!???<<' -b "" -s base


If the password is wrong, you will get an output like this one:
ldap_bind: Invalid credentials (49)

Otherwise it means that your DM password is OK.
HTH,
Flo.


On 09/13/2016 01:57 PM, Günther J. Niederwimmer wrote:

Hello,

FreeIPA 4.3.1

I like to install my new Startcom Cert and have a Problem with the access ?

I search and found this

ipa-cacert-manage -p '#-!???<<' -n STARTCOM-ROOT -t C,, install
1_root_bundle.crt

but I become this
Insufficient access:  Invalid credentials
The ipa-cacert-manage command failed.

Can I test the "DM" Password with a other command or is this a Problem with
ipa-cacert-manage?

I test it with "kinit admin" and without ?

or is this a Problem with the Password when I write this
ipa-cacert-manage -p #-!???<< -n STARTCOM-ROOT -t C,, install
1_root_bundle.crt

I have this answer

ipa-cacert-manage: error: -p option requires an argument

Thanks for a answer,



--
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] Question Test 3rd Party Certificate

[Florence Blanc-Renaud]

On 09/24/2016 02:37 PM, Günther J. Niederwimmer wrote:

Hello,

what is the best way to test a new installed 3rd Party certificate ?
I hope i have now install (with big problems) the new certificate on clients
and servers.

But now is the big question is this all working correct together (?), or have
i make a mistake ?

I like to install this on a productive server with two master and 8 clients
Freeipa 4.2 Centos 7 with all Updates

with MailServer, private Cloud, webserver, DNS server .

the next question is, what is in three years when the certificates expire ?
Is there a tested way to renew the certificate ?

I have search a long time in the internet but I can't found answers ?


Hi,

you can find the supported procedure here: Using 3rd part certificates 
for HTTP/LDAP [1].


We are currently working on improving the chapter "Managing Certificates 
and Certificate Authorities" of the "Linux Domain Identity, 
Authentication, and Policy Guide" [2]. If you feel that some information 
is missing, please file documentation bugs so that we can take your 
comments into account for the next revision.


Depending on your deployment constraints, you may also consider 
installing FreeIPA's certificate authority using ipa-ca-install. This 
would allow to have HTTP/LDAP certificates issued *and renewed 
automatically* by FreeIPA CA.


Hope this helps,
Flo.

[1] http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-certificates.html


Thanks for a answer,



--
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 IPA Servers with third-party certificate(external CA)

[Florence Blanc-Renaud]

On 09/29/2016 02:12 PM, Rob Crittenden wrote:

beeth beeth wrote:

Hi Florence,

I previously tried option a) and failed(need to find out why later), but
I was able to successfully reinstall the server and the client with
option b), thanks a lot! So when it says "Installing Without a CA", it
means without a "embeded CA"(the IPA's own CA), is that right?

Another main problem comes up for option b): now I am going to install
the replica server(ipa2), if I do the same as I did before:

[root@ipa1 ~]# ipa-replica-prepare ipa2.example.com
<http://ipa2.example.com>

copy the gpg file from ipa1 to ipa2

[root@ipa2 ~]# ipa-replica-install
/var/lib/ipa/replica-info-ipa2.example.com.gpg

Then I believe the Apache on ipa2(the replica server) will use the
Verisign certificate with the same hostname(DN): ipa1.example.com
<http://ipa1.example.com>, NOT ipa2.example.com
<http://ipa2.example.com>, hence the users who visit
https://ipa2.example.com will experience security warning from the
browser, as expected...
What could be a solution for this?

Thanks again!


On Thu, Sep 29, 2016 at 6:03 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 09/29/2016 11:43 AM, beeth beeth wrote:

Thanks for the quick response Florence!

My goal is the use a 3rd party certificate(such as Verisign
cert) for
Web UI(company security requirement), in fact we are not
required to use
3rd party certificate for the LDAP server, but as I mentioned
earlier, I
couldn't make the new Verisign cert to work with the Web UI,
without
messing up the IPA function(after I updated the nss.conf to use
the new
cert in the /etc/httpd/alias db, the ipa_client_install failed).
So I
tried to follow the Redhat instruction, to see if I can get the
Verisign
cert installed at the most beginning, without using FreeIPA's
own/default certificate), but I got the CSR question.

I did install IPA without a CA, by following the instruction at

https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

<https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP>,
but failed to restart HTTPD. When and how can I provide the
3rd-party
certificate? Could you please point me a document about the
detail?

Hi,

you need first to clarify if you want FreeIPA to act as a CA or not.
The setup will depend on this choice.

- option a) FreeIPA with an embedded CA:
you can install FreeIPA with a self-signed CA, then follow the
instructions at

https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

<https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP>
in order to replace the WebUI certificate. Please note that there
were some bugs in ipa-server-certinstall, preventing httpd from
starting (Ticket #4786 [1]). The workaround is to manually update
nss.conf (as you did) and manually import the CA certificate into
/etc/pki/pki-tomcat/alias, for instance with
$ certutil -A -d /etc/pki/pki-tomcat/alias -i cacert.pem -n nickname
-t C,,


- option b) Free IPA without CA
the installation instructions are in Installing without a CA [2].
You will provide the certificate that will be used by both the LDAP
server and the WebUI in the command options.


You'd need either a separate certificate or one with multiple subject
alternative names, one for each master. I also imagine you'd need to
provide this certificate at replica preparation time if you've installed
without a CA.

Yes, that's right. You can use the command ipa-replica-prepare with the 
options --dirsrv-cert-file / --dirsrv-pin and --http-cert-file / 
--http-pin to provide the replica's certificate and key. They will be 
embedded in the replica file and used during the replica installation.


Flo.


rob



HTH,
Flo.

[1] https://fedorahosted.org/freeipa/ticket/4786
<https://fedorahosted.org/freeipa/ticket/4786>
[2]

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca


<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca>








--
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] Want to extend schema for ipahost

[Florence Blanc-Renaud]

On 09/19/2016 01:31 PM, Deepak Dimri wrote:

Hi All,

I want to add couple of custom attribute to IPA Host. I have already
added custom attributes and objectclass "AWSInstanceDetails" to my
schema succesfully but when i am trying to modify existing host to
include the new objectclass i am getting below error

ldap_modify: Object class violation (65)

additional info: missing attribute "sn" required by object class
"AWSInstanceDetails"


my ldif file to add the newly created objectclass.


dn: fqdn=testhost,dc=ddiam,dd=online

changetype: modify

add: objectclass

objectclass: AWSInstanceDetails


How can i extend my ipahost objectclass to include additional
attributes? i followed this document to extend ipa
userobjectclass 
https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf but
now i need help with ipahost


As always any help would be much appreciated!


Thanks,

Deepak





Hi Deepak,

What is your schema definition for AWSInstanceDetails? If it requires 
the "sn" attribute as a mandatory attribute (i.e in the MUST section), 
then you need to define a value for sn in your ldif file. Otherwise the 
schema would not be respected by your object.


For instance:
dn: fqdn=testhost,dc=ddiam,dd=online
changetype: modify
add: objectclass
objectclass: AWSInstanceDetails
-
add: sn
sn: myValue

If, on the contrary, you do not want the attribute to be mandatory, you 
can define the AWSInstanceDetails objectclass with an optional "sn" 
attribute, by putting sn in the MAY section.


Hope this helps,
Flo.

--
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 Fails to build Replica (w/External CA)

[Florence Blanc-Renaud]

Hi Korey,

I believe that you are hitting Dogtag issue #2255 [1]. The file 
/tmp/ca.p12 probably doesn't contain the trust flags for some certificates.

You can check by running
pki pkcs12-cert-find --pkcs12-file /tmp/ca.p12 --pkcs12-password password
and see if the output displays "Trust Flags: xxx" for all the certs.

Flo.

[1] https://fedorahosted.org/pki/ticket/2255

On 09/21/2016 05:38 PM, Korey Chapman wrote:

On Wed, Sep 21, 2016 at 6:47 AM, Tomas Krizek  wrote:

On 09/21/2016 02:13 AM, Korey Chapman wrote:

Hello list,

I'm currently attempting to add a second CA server to our IPA cluster (all
servers Centos 7.2 with IPA 4.2.0). However, it is failing no matter how I
try to setup the CA (ipa-replica-install with --setup-ca or
ipa-replica-install followed by ipa-ca-install). The only useful thing in
the logs is an error about a missing key for "trust_flags" in the pki setup.
Our infrastructure uses FreeIPA with an external CA.

Any ideas/help would be greatly appreciated. Here are the logs snips from my
most recent attempt:

Command output snip from "ipa-replica-install
/root/replica-info-auth-002.XXX.gpg --setup-ca"
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
  [1/24]: creating certificate server user
  [2/24]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpYofMPt''
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.

ipa.ipapython.install.cli.install_tool(Replica): ERRORCA configuration
failed


Log snip from ipareplica-install.log:

2016-09-20T23:42:27Z DEBUG Starting external process
2016-09-20T23:42:27Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmpYofMPt'
2016-09-20T23:42:31Z DEBUG Process finished, return code=1
2016-09-20T23:42:31Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20160920234227.log
Loading deployment configuration from /tmp/tmpYofMPt.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.


2016-09-20T23:42:31Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
Traceback (most recent call last):
  File "/bin/pki", line 254, in 
cli.execute(sys.argv)
  File "/bin/pki", line 240, in execute
module.execute(module_args)
  File "/usr/lib/python2.7/site-packages/pki/cli/__init__.py", line 195, in
execute
module.execute(module_args)
  File "/usr/lib/python2.7/site-packages/pki/cli/pkcs12.py", line 222, in
execute
trust_flags = cert_info['trust_flags']
KeyError: 'trust_flags'


--
Korey


Hi Korey,

could you check if there is any more info in /var/log/pki/pki-ca-spawn log?


Nothing really useful I see in the spawn log:
2016-09-20 23:42:31 pkispawn: DEBUG... Error Type:
CalledProcessError
2016-09-20 23:42:31 pkispawn: DEBUG... Error Message:
Command '['pki', '-d', '/etc/pki/pki-tomcat/alias', '-C',
'/etc/pki/pki-tomcat/pfile', 'pkcs12-import', '--pkcs12-file',
'/tmp/ca.p12', '--pkcs12-password-file',
'/tmp/tmps5OOav/password.txt', '--no-user-certs']' returned non-zero
exit status 1
2016-09-20 23:42:31 pkispawn: DEBUG...   File
"/usr/sbin/pkispawn", line 597, in main
rv = scriptlet.spawn(deployer)
  File 
"/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/security_databases.py",
line 104, in spawn
no_user_certs=True)
  File "/usr/lib/python2.7/site-packages/pki/nssdb.py", line 538, in
import_pkcs12
subprocess.check_call(cmd)
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
raise CalledProcessError(retcode, cmd)



It might also be helpful verify if correct trust flags are set in nssdb:
certutil -d /etc/pki/pki-tomcat/alias/ -L



Run on the source ipa server (current CA server):
$ certutil -d /etc/pki/pki-tomcat/alias/ -L

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

XXX Certificate Authority CT,c,
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca   

Re: [Freeipa-users] 3rd party Cert install now IPA total broken

[Florence Blanc-Renaud]

On 09/20/2016 02:15 PM, Günther J. Niederwimmer wrote:

Hello.

Thanks for the first help,

Am Montag, 19. September 2016, 12:02:19 schrieb Florence Blanc-Renaud:

On 09/16/2016 03:06 PM, Günther J. Niederwimmer wrote:

Hello,
Freeipa 4.3.1

I have now install a 3rd Party Certificat from Startcom now my IPA is
total
broken?



ipa-cacert-manage -p '' -n STARTCOM-ROOT -t C,, install
root.crt


I mean this is the wrong cert I installed :-(.

Is it possible to overwrite or delete and make it new. this file is the ROOT-CA
from STARTCOM ("30 Years")


Hi,

ipa-cacert-manage install *adds* the CA certificate to the list of CA 
certs (it does not replace the CA cert), meaning that it can be run 
multiple times with different certificates. After this step, you can 
find all your CA certificates in the ldap server, below 
cn=certificates,cn=ipa,cn=etc,$BASEDN


So in your case, you can re-run this command, this time with the right 
CA cert. Then do not forget to run ipa-certupdate on all the ipa 
replicas/clients in order to install the new CA cert on the relevant NSS 
databases. It is important to run ipa-certupdate before IPA services are 
restarted with the new certs (otherwise ipa-certupdate cannot contact 
the LDAP server to download the new certificates).


If you forgot to run ipa-certupdate on the clients, I guess you can fix 
this by installing the new CA cert in /etc/ipa/nssdb with C,, flags.


HTH,
Flo


ipa-certupdate

ipa-server-certinstall -w -d ipa_3rd_ca.p12


This was wrong, I delete all this installed certs with
Certutil -d . -D -n xxx


I create this p12 with key.pem, cert.pem root.crt


now i create a new p12 with I hope the correct certs

I become from Startcom a httpd zip file with 1_root_bundle.crt ("15 Years")and
my wild-card Certificate this I included in my new created p12 with my key.pem.

This p12 I Installed on the first master with

pk12util -v -i ipa_4gjn_ca.p12 -d /etc/httpd/alias -k
/etc/httpd/alias/pwdfile.txt -W 

pk12util -v -i ipa_4gjn_ca.p12 -d /etc/dirsrv/slapd-4GJN-COM -k
/etc/dirsrv/slapd-4GJN-COM/pwdfile.txt -W xxx
and
pk12util -v -i ipa_4gjn_ca.p12 -d /var/lib/pki/pki-tomcat/alias -k
/etc/pki/pki-tomcat/pwdfile.txt -W x

I change the nss.conf and I hope the correct file in /etc/dirsrv/slapd-
/dsl.ldif

Then I change in all NSS DB the StartCOM Cert (1_root_bundle.crt) with name
STARTCOM-ROOT to
certutil -d . -M -t C,, -n STARCOM-ROOT


afterward I make a reboot and a test
ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-ods-exporter Service: STOPPED
ods-enforcerd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

Why is ipa-ods-exporter Service always STOPPED ??

The next I Test a login on the Web UI from IPA, this is now also working ;-)


the QUESTION is now what is with the second master and the IPA- clients
Now (?) I have also found the ipa-backup ;-) OK, for the next Problem now I
know it :-).

Have I to repeat this all on the second Master ?

and what is the correct way to inform the clients ?

Thanks again for a answer,


Hi,

there were some issues with ipa-server-certinstall (see tickets #4785,
#4786 and #6263).
In order to check your configuration, you must make sure that the NSS
DBs for Apache and the LDAP server (/etc/httpd/alias,
/var/lib/pki/pki-tomcat/alias, /etc/dirsrv/slapd-DOMxx) contain:
- the server certificate with flags u,u,u (= the one contained in
ipa_3rd_ca.p12)
- the certificate of the CA which signed the server certificate, with
flags C,, (= the one contained in root.rt)

Then you can also check if the nickname for the server cert is properly
set in /etc/httpd/conf.d/nss.conf (in the directive NSSNickname), and in
the LDAP entry cn=RSA,cn=encryption,cn=config (in the attribute
nsSSLPersonalitySSL).

If this doesn't fix the issue, the logs of pki-tomcat/ca/debug may
provide more information.

Also note that it is important to run ipa-certupdate on all the clients
and replicas in order to install the new certificates in the NSS DBs
*before* you run ipa-server-certinstall.

Hope this helps,
Flo.


the kerberos don't start anymore ?
The Error Is

 Unspecified GSS failure.Minor (2529639068): Cannot contact any KDC for
 realm>
'4GJN.COM'

after insert in nss.conf
"NSSEnforceValidCerts off"

ipactl restart  is starting (?) but

ipactl status tell me
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-ods-exporter Service: STOPPED
ods-enforcerd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

with 

Re: [Freeipa-users] 3rd party Cert install now IPA total broken

[Florence Blanc-Renaud]

On 09/16/2016 03:06 PM, Günther J. Niederwimmer wrote:

Hello,
Freeipa 4.3.1

I have now install a 3rd Party Certificat from Startcom now my IPA is total
broken?
I make this

ipa-cacert-manage -p '' -n STARTCOM-ROOT -t C,, install
root.crt

ipa-certupdate

ipa-server-certinstall -w -d ipa_3rd_ca.p12

I create this p12 with key.pem, cert.pem root.crt

I insert also in the cert.pem the intermediate.crt


Hi,

there were some issues with ipa-server-certinstall (see tickets #4785, 
#4786 and #6263).
In order to check your configuration, you must make sure that the NSS 
DBs for Apache and the LDAP server (/etc/httpd/alias, 
/var/lib/pki/pki-tomcat/alias, /etc/dirsrv/slapd-DOMxx) contain:
- the server certificate with flags u,u,u (= the one contained in 
ipa_3rd_ca.p12)
- the certificate of the CA which signed the server certificate, with 
flags C,, (= the one contained in root.rt)


Then you can also check if the nickname for the server cert is properly 
set in /etc/httpd/conf.d/nss.conf (in the directive NSSNickname), and in 
the LDAP entry cn=RSA,cn=encryption,cn=config (in the attribute 
nsSSLPersonalitySSL).


If this doesn't fix the issue, the logs of pki-tomcat/ca/debug may 
provide more information.


Also note that it is important to run ipa-certupdate on all the clients 
and replicas in order to install the new certificates in the NSS DBs 
*before* you run ipa-server-certinstall.


Hope this helps,
Flo.


the kerberos don't start anymore ?
The Error Is
 Unspecified GSS failure.Minor (2529639068): Cannot contact any KDC for realm
'4GJN.COM'

after insert in nss.conf
"NSSEnforceValidCerts off"

ipactl restart  is starting (?) but

ipactl status tell me
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-ods-exporter Service: STOPPED
ods-enforcerd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

with certutil -d /etc/httpd/alias -L I have now this
Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
4GJN_CA_FILE u,u,u
ipaCert  u,u,u
4GJN.COM IPA CA  CT,C,C
STARTCOM-ROOTC,,

I can  Insert in nss.conf by the
#NSSNickname "Signing-Cert" original
or
NSSNickname 4GJN_CA_FILE but all is now broken ?

I also add this, found in Bugzilla
 certutil -d /var/lib/pki/pki-tomcat/alias -L

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

ocspSigningCert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
STARTCOM-ROOTCT,,

this is created in the

certutil -d /etc/dirsrv/slapd-4GJN.COM -L

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

4GJN_CA_FILE u,u,u
4GJN.COM IPA CA  CT,C,C
STARTCOM-ROOTC,,

Can any help a little, please ;-)

The bad Problem, I tested this with my master server with DNS / DNSSEC I can't
new install (DNSSEC Keys)



--
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 IPA Servers with third-party certificate(external CA)

[Florence Blanc-Renaud]

Hi,

The instructions that you followed are used when you want to install 
FreeIPA with an embedded Certificate Authority (ie FreeIPA is able to 
issue certificates), and FreeIPA CA is signed by a 3rd party CA.


Maybe your goal is just to use a 3rd party certificate for IPA's LDAP 
server and Web UI. In this case, you do not need to install FreeIPA with 
an embedded CA. You can follow the instructions for Installing without a 
CA [1], where you will need to provide a 3rd-part certificate.


Hope this clarifies,
Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca



On 09/29/2016 11:03 AM, beeth beeth wrote:

I am trying to set up IPA servers with Verisign certificate, so that the
Admin Web console can use public signed certificate to meet company's
security requirement. But when I try to follow Red Hat's instructions at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca,

2.3.5. Installing a Server with an External CA as the Root CA,
at the first step it says to generate CSR by adding the --external-ca
option to the ipa-server-install utility, which does generate a CRS at
/root/ipa.csr. However, the ipa-server-install command in fact doesn't
ask for Distinguished Name (DN) or the organization info(like country,
state, etc.), which are required in the CSR. Without a valid CSR file, I
can't request for new Verisign certs. Did I miss something?

Originally I once tried to change the default certificate for Apache(the
Web Admin console) ONLY to the Verisign one, by adding the certificates
to the /etc/httpd/alias database with the command:
  # ipa-server-certinstall -w --http_pin=test verisign.pk12
And updated the nss.conf for httpd, so that the new Nickname is used to
point to the Verisign certs. That worked well for the website. However,
the IPA client installation failed after that for the "ipa-client-install":

ERROR Joining realm failed: libcurl failed to execute the HTTP POST
transaction, explaining:  Peer's certificate issuer has been marked as
not trusted by the user.

Even I tried to also update the certificate for the Directory
service(ipa-server-certinstall -d ... ), the client installation still
failed. I believe the new Verisign cert messed up the communication of
the IPA components. Then I am thinking to install the IPA server from
scratch with the Verisign cert, but then I hit the CSR problem described
above.

Please advise. Thanks!




--
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 IPA Servers with third-party certificate(external CA)

[Florence Blanc-Renaud]

On 09/29/2016 11:43 AM, beeth beeth wrote:

Thanks for the quick response Florence!

My goal is the use a 3rd party certificate(such as Verisign cert) for
Web UI(company security requirement), in fact we are not required to use
3rd party certificate for the LDAP server, but as I mentioned earlier, I
couldn't make the new Verisign cert to work with the Web UI, without
messing up the IPA function(after I updated the nss.conf to use the new
cert in the /etc/httpd/alias db, the ipa_client_install failed). So I
tried to follow the Redhat instruction, to see if I can get the Verisign
cert installed at the most beginning, without using FreeIPA's
own/default certificate), but I got the CSR question.

I did install IPA without a CA, by following the instruction at
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP,
but failed to restart HTTPD. When and how can I provide the 3rd-party
certificate? Could you please point me a document about the detail?

Hi,

you need first to clarify if you want FreeIPA to act as a CA or not. The 
setup will depend on this choice.


- option a) FreeIPA with an embedded CA:
you can install FreeIPA with a self-signed CA, then follow the 
instructions at 
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP 
in order to replace the WebUI certificate. Please note that there were 
some bugs in ipa-server-certinstall, preventing httpd from starting 
(Ticket #4786 [1]). The workaround is to manually update nss.conf (as 
you did) and manually import the CA certificate into 
/etc/pki/pki-tomcat/alias, for instance with

$ certutil -A -d /etc/pki/pki-tomcat/alias -i cacert.pem -n nickname -t C,,


- option b) Free IPA without CA
the installation instructions are in Installing without a CA [2]. You 
will provide the certificate that will be used by both the LDAP server 
and the WebUI in the command options.


HTH,
Flo.

[1] https://fedorahosted.org/freeipa/ticket/4786
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca



Thanks again!


On Thu, Sep 29, 2016 at 5:25 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

Hi,

The instructions that you followed are used when you want to install
FreeIPA with an embedded Certificate Authority (ie FreeIPA is able
to issue certificates), and FreeIPA CA is signed by a 3rd party CA.

Maybe your goal is just to use a 3rd party certificate for IPA's
LDAP server and Web UI. In this case, you do not need to install
FreeIPA with an embedded CA. You can follow the instructions for
Installing without a CA [1], where you will need to provide a
3rd-part certificate.

Hope this clarifies,
Flo.

[1]

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca>



On 09/29/2016 11:03 AM, beeth beeth wrote:

I am trying to set up IPA servers with Verisign certificate, so
that the
Admin Web console can use public signed certificate to meet
company's
security requirement. But when I try to follow Red Hat's
instructions at

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca>,

2.3.5. Installing a Server with an External CA as the Root CA,
at the first step it says to generate CSR by adding the
--external-ca
option to the ipa-server-install utility, which does generate a
CRS at
/root/ipa.csr. However, the ipa-server-install command in fact
doesn't
ask for Distinguished Name (DN) or the organization info(like
country,
state, etc.), which are required in the CSR. Without a valid CSR
file, I
can't request for new Verisign certs. Did I miss something?

Originally I once tried to change the default certificate for
Apache(the
Web Admin console) ONLY to the Verisign one, by adding the
certificates
to the /etc/httpd/alias database with the command:
  # ipa-server-certinstall -w --http_pin=test verisign.pk12
And updated the nss.conf for httpd, so that the new Nickname is
used to
point to the Verisign certs. That worked well for the website.
However,
the IPA client i

Re: [Freeipa-users] How to get a new cert

[Florence Blanc-Renaud]

Hi Bret,

would the following be helpful? In "Linux Domain Identity, 
Authentication, and Policy Guide", Chapter 17.1.1 Requesting New 
Certificates for a User, Host, or Service [1]


Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request


On 09/27/2016 04:20 PM, Bret Wortman wrote:

Is there a guide anywhere for how to obtain an SSL certificate for a new
server & service from the IPA CA master? Most of the guides I'm seeing
online use web pages at the major CAs to do this and I'd like to keep it
in the family.

Thanks!


--
*Bret Wortman*

http://wrapbuddies.co/




--
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 get a new cert

[Florence Blanc-Renaud]

On 09/27/2016 08:00 PM, Bret Wortman wrote:

That looks like it worked, but I have a follow-on question:

I need to provide my RabbitMQ instance with a cacert file, a cert, and a
key file. These seem to be .pem files. Is there an easy way to gather
these 3 files from a typical IPA client node?


Hi,

you can retrieve the new cert using the GUI. Navigate to Identity tab, 
then Users or Hosts or Services and pick your user, host or service. You 
will find in the "Actions" button a command to "Get Certificate". This 
will open a new window with the content of the cert, that you can 
copy/paste into mycert.pem.


Once you have obtained mycert.pem, you can add it to the NSS database 
that you used previously in order to generate the CSR:

$ certutil -A -d path_to_database -i mycert.pem -t u,u,u -n mycert

Add IPA CA to the nss database:
$ certutil -A -d path_to_database -n "IPA CA" -t CT,, -a < /etc/ipa/ca.crt

Then pk12util and openssl will allow you to extract the key and certs 
through a temp keys.p12 file:

$ pk12util -o keys.p12 -n mycert -d path_to_database
$ openssl pkcs12 -in keys.p12 -out mykey.pem -nodes

The output is mykey.pem which contains the key, the new certificate and 
IPA CA certificate.


HTH,
Flo.


Merci!


Bret


On 09/27/2016 11:28 AM, Florence Blanc-Renaud wrote:

Hi Bret,

would the following be helpful? In "Linux Domain Identity,
Authentication, and Policy Guide", Chapter 17.1.1 Requesting New
Certificates for a User, Host, or Service [1]

Flo.

[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certificates.html#certificate-request


On 09/27/2016 04:20 PM, Bret Wortman wrote:

Is there a guide anywhere for how to obtain an SSL certificate for a new
server & service from the IPA CA master? Most of the guides I'm seeing
online use web pages at the major CAs to do this and I'd like to keep it
in the family.

Thanks!


--
*Bret Wortman*
<http://wrapbuddies.co/>
http://wrapbuddies.co/








--
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] Renew / Replace third-party certificate for IPA Servers(primary and replica)

[Florence Blanc-Renaud]

On 10/20/2016 05:05 AM, beeth beeth wrote:

First of all, thanks for the quick response Florence!

I have question about your suggested step [1] and [2]:
For [1],  "ipa-cacert-manage install cert.pem". Which certificate is
this? Is it the ChainBundle cert(root cert + intermediate cert)?
For [2],  "ipa-server-certinstall -d /path/to/pkcs12.p12" . Which
certificate is this pkcs12.p12? Is it the Server cert?

Here's exactly what I ran initially to install the IPA server with the
Verisign certs, by following your suggestion last time(at the Admin
manual 2.3.6. Installing Without a CA), and it worked well:

# ipa-server-install --http-cert-file ServerCertificate.crt
--http-cert-file ipaserver1.encrypted.key --http-pin MYipakey
--dirsrv-cert-file ServerCertificate.crt --dirsrv-cert-file
ipaserver1.encrypted.key --dirsrv-pin MYipakey --ca-cert-file
ChainBundle2.crt

So, basically the installation requested 3 items: the server
key(ipaserver1.encrypted.key), the server certificate from
Verisign(ServerCertificate.crt), and the "root+intermediate" certs from
Verisign(ChainBundle2.crt).
Now let's say such Verisign certificate expires, and I want to replace
the certs from GoDaddy(another public cert provider), I assume a new set
of certs, including the new key, the new server cert, and the new Chain
cert(root+intermediate), total 3 items, will need to be included in the
commands for the third party certificate replacement.
The steps [1] and [2] only show two inputs, so I am not sure what I have
been missing.


Hi,

Sorry if I was not clear enough. The first step (ipa-cacert-manage 
install) aims at adding the CA certificate thus the root+intermediate 
certs should be provided.


The step with ipa-server-certinstall configures the Server Cert (-d if 
you want to replace the LDAP cert, -w for HTTP cert), meaning that the 
Server-Cert and key should be provided. The man page details all the 
supported formats, and it is possible to provide multiple files.


Hope this clarifies,
Flo.


Please advise the detail. Thanks again!
Beeth


On Wed, Oct 19, 2016 at 11:49 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 10/19/2016 05:23 PM, beeth beeth wrote:

I once asked about Install IPA servers with certificate provided by
third-party like

Verisign(https://www.redhat.com/archives/freeipa-users/2016-September/msg00440.html

<https://www.redhat.com/archives/freeipa-users/2016-September/msg00440.html>

<https://www.redhat.com/archives/freeipa-users/2016-September/msg00440.html

<https://www.redhat.com/archives/freeipa-users/2016-September/msg00440.html>>).
Florence, Rob and Jakub from Redhat had been very helpful, and
pointed
out the solution at

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca>

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca>>,
about "Installing Without a CA", and it worked great!

Now it came up another problem, is that the Verisign(or any other
certificate) will expire in a year or two, how can I smoothly
renew the
Verisign certificate on the primary and replica IPA servers a
year from
now? Or if we decide to use another provider, say Godaddy
certificate,
how can I replace the existing certificate on both IPA servers?
I found
a relevant instruction at

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#auto-cert-renewal

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#auto-cert-renewal>

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#auto-cert-renewal

<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#auto-cert-renewal>>,
but that's about the "Dogtag" CA certificate, not about the
third-party
certificate I 

Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue

[Florence Blanc-Renaud]

On 10/19/2016 08:18 PM, Bertrand Rétif wrote:

*De: *"Bertrand Rétif" 

*À: *freeipa-users@redhat.com
*Envoyé: *Mercredi 19 Octobre 2016 15:42:07
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue




*De: *"Rob Crittenden" 
*À: *"Bertrand Rétif" ,
freeipa-users@redhat.com
*Envoyé: *Mercredi 19 Octobre 2016 15:30:14
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue

Bertrand Rétif wrote:
>> De: "Martin Babinsky" 
>> À: freeipa-users@redhat.com
>> Envoyé: Mercredi 19 Octobre 2016 08:45:49
>> Objet: Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue
>
>> On 10/18/2016 11:22 PM, Bertrand Rétif wrote:
>>> Hello,
>>>
>>> I had an issue with pki-tomcat.
>>> I had serveral certificate that was expired and pki-tomcat
did not start
>>> anymore.
>>>
>>> I set the dateon the server before certificate expiration
and then
>>> pki-tomcat starts properly.
>>> Then I try to resubmit the certificate, but I get below error:
>>> "Profile caServerCert Not Found"
>>>
>>> Do you have any idea how I could fix this issue.
>>>
>>> Please find below output of commands:
>>>
>>>
>>> # getcert resubmit -i 20160108170324
>>>
>>> # getcert list -i 20160108170324
>>> Number of certificates and requests being tracked: 7.
>>> Request ID '20160108170324':
>>> status: MONITORING
>>> ca-error: Server at
>>> "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit;
replied:
>>> Profile caServerCert Not Found
>>> 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=A.SKINFRA.EU
>>> subject: CN=IPA RA,O=A.SKINFRA.EU
>>> expires: 2016-06-28 15:25:11 UTC
>>> key usage:
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>> eku: id-kp-serverAuth,id-kp-clientAuth
>>> pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
>>> track: yes
>>> auto-renew: yes
>>>
>>>
>>> Thanksby advance for your help.
>>> Bertrand
>>>
>>>
>>>
>>>
>
>> Hi Betrand,
>
>> what version of FreeIPA and Dogtag are you running?
>
>> Also perform the following search on the IPA master and post
the result:
>
>> """
>> ldapsearch -D "cn=Directory Manager" -W -b
>> 'ou=certificateProfiles,ou=ca,o=ipaca'
'(objectClass=certProfile)'
>> """
>
> Hi Martin,
>
> Thanks for your reply.
>
> Here is version:
> - FreeIPA 4.2.0
> - Centos 7.2
>
> I have been able to fix the issue with "Profile caServerCert
Not Found" by editing /var/lib/pki/pki-tomcat/ca/conf/CS.cfg
> I replace below entry
>
"subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem"
> by
> "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem"
>
> and then launch "ipa-server-upgrade" command
> I found this solution in this post:
http://osdir.com/ml/freeipa-users/2016-03/msg00280.html
>
> Then I was able to renew my certificate.
>
> However I reboot my server to and pki-tomcat do not start and
provide with a new erreor in /var/log/pki/pki-tomcat/ca/debug
>
> [19/Oct/2016:11:11:52][localhost-startStop-1]: CertUtils:
verifySystemCertByNickname() passed: auditSigningCert cert-pki-ca
> [19/Oct/2016:11:11:52][localhost-startStop-1]:
SignedAuditEventFactory: create()
message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$
> System$][Outcome=Success][CertNickName=auditSigningCert
cert-pki-ca] CIMC certificate verification
>
> java.lang.Exception: SystemCertsVerification: system certs
verification failure
> at

com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198)
> at

Re: [Freeipa-users] Renew / Replace third-party certificate for IPA Servers(primary and replica)

[Florence Blanc-Renaud]

On 10/19/2016 05:23 PM, beeth beeth wrote:

I once asked about Install IPA servers with certificate provided by
third-party like
Verisign(https://www.redhat.com/archives/freeipa-users/2016-September/msg00440.html
).
Florence, Rob and Jakub from Redhat had been very helpful, and pointed
out the solution at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-ca
,
about "Installing Without a CA", and it worked great!

Now it came up another problem, is that the Verisign(or any other
certificate) will expire in a year or two, how can I smoothly renew the
Verisign certificate on the primary and replica IPA servers a year from
now? Or if we decide to use another provider, say Godaddy certificate,
how can I replace the existing certificate on both IPA servers? I found
a relevant instruction at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#auto-cert-renewal
,
but that's about the "Dogtag" CA certificate, not about the third-party
certificate I am using in our upcoming production environment(running
IPA 4.2 on RHEL7).


Hi,

if you plan to use another CA (for instance switch from Verisign to 
Godaddy), you will need first to install the new CA certificate with 
ipa-cacert-manage install and ipa-certupdate. The instructions are in 
30.4 Manual CA Certificate Installation [1].


Then, if you want to change the HTTP and LDAP certificates for your 
server, you can use the ipa-server-certinstall utility [2].


[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#manual-cert-install


[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#Configuring_Certificates_and_Certificate_Authorities


Hope this helps,
Flo.


Please advise. Thank you!
Beeth


--
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] Impossible to renew certificate. pki-tomcat issue

[Florence Blanc-Renaud]

On 11/22/2016 06:06 PM, Bertrand Rétif wrote:

Hi Florence,

Thanks for clarification.
Your explanation was very clear and I better understand

Now my issue is that I need to start tracking "auditSigningCert
cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert
cert-pki-ca" on a server.

I take a look on another server where they are properly tracked. However
getcert list return me "pin set" and not a "pinfile" as described in
your mail.
In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, so my
question is where do I get the PIN?


Hi Bertrand,

With IPA 4.2.0 I believe that the pin is stored in 
/var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field:

$ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
internal=0123456789101

HTH,
Flo


Once again, thanks for your support, I tried to fix this issue for days!

Regards
Bertrand


--
Bertrand Rétif
Phosphore Services Informatiques - http://www.phosphore.eu
Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44

--------

*De: *"Florence Blanc-Renaud" <f...@redhat.com>
*À: *"Bertrand Rétif" <bre...@phosphore.eu>, freeipa-users@redhat.com
*Envoyé: *Mardi 22 Novembre 2016 13:17:34
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue

    On 11/22/2016 11:50 AM, Bertrand Rétif wrote:
>
>
> *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
freeipa-users@redhat.com
> *Envoyé: *Mardi 22 Novembre 2016 11:33:45
> *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> pki-tomcat issue
>
> On 11/22/2016 10:07 AM, Bertrand Rétif wrote:
> >
>

> >
> > *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> > *À: *freeipa-users@redhat.com
> > *Envoyé: *Mardi 25 Octobre 2016 17:51:09
> > *Objet: *Re: [Freeipa-users] Impossible to renew
    certificate.
> > pki-tomcat issue
> >
> >
> >
>

> >
> > *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> > *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> > freeipa-users@redhat.com
> > *Envoyé: *Jeudi 20 Octobre 2016 18:45:21
> > *Objet: *Re: [Freeipa-users] Impossible to renew
certificate.
> > pki-tomcat issue
> >
> > On 10/19/2016 08:18 PM, Bertrand Rétif wrote:
> > > *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> > >
> > > *À: *freeipa-users@redhat.com
> > > *Envoyé: *Mercredi 19 Octobre 2016 15:42:07
> > > *Objet: *Re: [Freeipa-users] Impossible to renew
> certificate.
> > > pki-tomcat issue
> > >
> > >
> > >
> >
>

> > >
> > > *De: *"Rob Crittenden" <rcrit...@redhat.com>
> > > *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> > > freeipa-users@redhat.com
> > > *Envoyé: *Mercredi 19 Octobre 2016 15:30:14
> > > *Objet: *Re: [Freeipa-users] Impossible to
renew
> > certificate.
> > > pki-tomcat issue
> > >
> > > Bertrand Rétif wrote:
> > > >> De: "Martin Babinsky" <mbabi...@redhat.com>
> > > >> À: freeipa-users@redhat.com
> > > >> Envoyé: Mercredi 19 Octobre 2016 08:45:49
> > > >> Objet: Re: [Freeipa-users] Impossible
to renew
> > certificate.
> > > pki-tomcat issue
> > > >
> > > >> On 10/18/2016 11:22 PM, Bertrand Rétif
wrote:
> > &g

Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue

[Florence Blanc-Renaud]

On 11/22/2016 11:50 AM, Bertrand Rétif wrote:



*De: *"Florence Blanc-Renaud" <f...@redhat.com>
*À: *"Bertrand Rétif" <bre...@phosphore.eu>, freeipa-users@redhat.com
*Envoyé: *Mardi 22 Novembre 2016 11:33:45
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue

On 11/22/2016 10:07 AM, Bertrand Rétif wrote:
>

>
> *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> *À: *freeipa-users@redhat.com
> *Envoyé: *Mardi 25 Octobre 2016 17:51:09
> *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> pki-tomcat issue
>
>
>
--------
>
> *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> freeipa-users@redhat.com
> *Envoyé: *Jeudi 20 Octobre 2016 18:45:21
> *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> pki-tomcat issue
>
> On 10/19/2016 08:18 PM, Bertrand Rétif wrote:
> > *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> >
> > *À: *freeipa-users@redhat.com
> > *Envoyé: *Mercredi 19 Octobre 2016 15:42:07
> > *Objet: *Re: [Freeipa-users] Impossible to renew
certificate.
> > pki-tomcat issue
> >
> >
> >
>

> >
> > *De: *"Rob Crittenden" <rcrit...@redhat.com>
> > *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> > freeipa-users@redhat.com
> > *Envoyé: *Mercredi 19 Octobre 2016 15:30:14
> > *Objet: *Re: [Freeipa-users] Impossible to renew
> certificate.
> > pki-tomcat issue
> >
> > Bertrand Rétif wrote:
> > >> De: "Martin Babinsky" <mbabi...@redhat.com>
> > >> À: freeipa-users@redhat.com
> > >> Envoyé: Mercredi 19 Octobre 2016 08:45:49
> > >> Objet: Re: [Freeipa-users] Impossible to renew
> certificate.
> > pki-tomcat issue
> > >
> > >> On 10/18/2016 11:22 PM, Bertrand Rétif wrote:
> > >>> Hello,
> > >>>
> > >>> I had an issue with pki-tomcat.
> > >>> I had serveral certificate that was expired and
> pki-tomcat
> > did not start
> > >>> anymore.
> > >>>
> > >>> I set the dateon the server before certificate
> expiration
> > and then
> > >>> pki-tomcat starts properly.
> > >>> Then I try to resubmit the certificate, but
I get
> below error:
> > >>> "Profile caServerCert Not Found"
> > >>>
> > >>> Do you have any idea how I could fix this issue.
> > >>>
> > >>> Please find below output of commands:
> > >>>
> > >>>
> > >>> # getcert resubmit -i 20160108170324
> > >>>
> > >>> # getcert list -i 20160108170324
> > >>> Number of certificates and requests being
tracked: 7.
> > >>> Request ID '20160108170324':
> > >>> status: MONITORING
> > >>> ca-error: Server at
> > >>>
> "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit;
> > replied:
> > >>> Profile caServerCert Not Found
> > >>> stuck: no
> > >>> key pair storage:
&

Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue

[Florence Blanc-Renaud]

On 11/22/2016 10:07 AM, Bertrand Rétif wrote:



*De: *"Bertrand Rétif" <bre...@phosphore.eu>
*À: *freeipa-users@redhat.com
*Envoyé: *Mardi 25 Octobre 2016 17:51:09
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue




    *De: *"Florence Blanc-Renaud" <f...@redhat.com>
*À: *"Bertrand Rétif" <bre...@phosphore.eu>,
freeipa-users@redhat.com
*Envoyé: *Jeudi 20 Octobre 2016 18:45:21
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue

On 10/19/2016 08:18 PM, Bertrand Rétif wrote:
> *De: *"Bertrand Rétif" <bre...@phosphore.eu>
>
> *À: *freeipa-users@redhat.com
> *Envoyé: *Mercredi 19 Octobre 2016 15:42:07
> *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> pki-tomcat issue
>
>
>

>
> *De: *"Rob Crittenden" <rcrit...@redhat.com>
> *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> freeipa-users@redhat.com
> *Envoyé: *Mercredi 19 Octobre 2016 15:30:14
> *Objet: *Re: [Freeipa-users] Impossible to renew
certificate.
> pki-tomcat issue
>
> Bertrand Rétif wrote:
> >> De: "Martin Babinsky" <mbabi...@redhat.com>
> >> À: freeipa-users@redhat.com
> >> Envoyé: Mercredi 19 Octobre 2016 08:45:49
> >> Objet: Re: [Freeipa-users] Impossible to renew
certificate.
> pki-tomcat issue
> >
> >> On 10/18/2016 11:22 PM, Bertrand Rétif wrote:
> >>> Hello,
> >>>
> >>> I had an issue with pki-tomcat.
> >>> I had serveral certificate that was expired and
pki-tomcat
> did not start
> >>> anymore.
> >>>
> >>> I set the dateon the server before certificate
expiration
> and then
> >>> pki-tomcat starts properly.
> >>> Then I try to resubmit the certificate, but I get
below error:
> >>> "Profile caServerCert Not Found"
> >>>
> >>> Do you have any idea how I could fix this issue.
> >>>
> >>> Please find below output of commands:
> >>>
> >>>
> >>> # getcert resubmit -i 20160108170324
> >>>
> >>> # getcert list -i 20160108170324
> >>> Number of certificates and requests being tracked: 7.
> >>> Request ID '20160108170324':
> >>> status: MONITORING
> >>> ca-error: Server at
> >>>
"http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit;
> replied:
> >>> Profile caServerCert Not Found
> >>> 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=A.SKINFRA.EU
> >>> subject: CN=IPA RA,O=A.SKINFRA.EU
> >>> expires: 2016-06-28 15:25:11 UTC
> >>> key usage:
> >>>
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> >>> eku: id-kp-serverAuth,id-kp-clientAuth
> >>> pre-save command:
/usr/lib64/ipa/certmonger/renew_ra_cert_pre
> >>> post-sa

Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue

[Florence Blanc-Renaud]

On 11/23/2016 02:25 PM, Bertrand Rétif wrote:




*De: *"Florence Blanc-Renaud" <f...@redhat.com>
*À: *"Bertrand Rétif" <bre...@phosphore.eu>, freeipa-users@redhat.com
*Envoyé: *Mercredi 23 Novembre 2016 08:49:28
*Objet: *Re: [Freeipa-users] Impossible to renew certificate.
pki-tomcat issue

On 11/22/2016 06:06 PM, Bertrand Rétif wrote:
> Hi Florence,
>
> Thanks for clarification.
> Your explanation was very clear and I better understand
>
> Now my issue is that I need to start tracking "auditSigningCert
> cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert
> cert-pki-ca" on a server.
>
> I take a look on another server where they are properly tracked.
However
> getcert list return me "pin set" and not a "pinfile" as described in
> your mail.
> In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file,
so my
> question is where do I get the PIN?
>
Hi Bertrand,

With IPA 4.2.0 I believe that the pin is stored in
/var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field:
$ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
internal=0123456789101

HTH,
Flo

> Once again, thanks for your support, I tried to fix this issue for
days!
>
> Regards
> Bertrand
>
>
> --
> Bertrand Rétif
> Phosphore Services Informatiques - http://www.phosphore.eu
> Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44
>
>

>
> *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
freeipa-users@redhat.com
> *Envoyé: *Mardi 22 Novembre 2016 13:17:34
> *Objet: *Re: [Freeipa-users] Impossible to renew certificate.
> pki-tomcat issue
>
> On 11/22/2016 11:50 AM, Bertrand Rétif wrote:
> >
> >
> > *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> > *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> freeipa-users@redhat.com
> > *Envoyé: *Mardi 22 Novembre 2016 11:33:45
> > *Objet: *Re: [Freeipa-users] Impossible to renew
certificate.
> > pki-tomcat issue
> >
> > On 11/22/2016 10:07 AM, Bertrand Rétif wrote:
> > >
> >
>

> > >
> > > *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> > > *À: *freeipa-users@redhat.com
> > > *Envoyé: *Mardi 25 Octobre 2016 17:51:09
> > > *Objet: *Re: [Freeipa-users] Impossible to renew
> certificate.
> > > pki-tomcat issue
> > >
> > >
> > >
> >
>

> > >
> > > *De: *"Florence Blanc-Renaud" <f...@redhat.com>
> > > *À: *"Bertrand Rétif" <bre...@phosphore.eu>,
> > > freeipa-users@redhat.com
> > > *Envoyé: *Jeudi 20 Octobre 2016 18:45:21
> > > *Objet: *Re: [Freeipa-users] Impossible to renew
> certificate.
> > > pki-tomcat issue
> > >
> > > On 10/19/2016 08:18 PM, Bertrand Rétif wrote:
> > > > *De: *"Bertrand Rétif" <bre...@phosphore.eu>
> > > >
> > > > *À: *freeipa-users@redhat.com
> > > > *Envoyé: *Mercredi 19 Octobre 2016 15:42:07
> > > > *Objet: *Re: [Freeipa-users] Impossible
to renew
> > certificate.
> > > > pki-tomcat issue
> > > >
> > > >
> > > >
> > >
> >
>

> > > >
> > &g

Re: [Freeipa-users] My IPA installation doesn't work after upgrade

[Florence Blanc-Renaud]

On 11/17/2016 12:09 PM, Morgan Marodin wrote:

Hello.

This morning I've tried to upgrade my IPA server, but the upgrade
failed, and now the service doesn't start! :(

If I try lo launch the upgrade manually this is the output:
/[root@mlv-ipa01 download]# ipa-server-upgrade
Upgrading IPA:
  [1/8]: saving configuration
  [2/8]: disabling listeners
  [3/8]: enabling DS global lock
  [4/8]: starting directory server
  [5/8]: updating schema
  [6/8]: upgrading server
  [7/8]: stopping directory server
  [8/8]: restoring configuration
Done.
Update complete
Upgrading IPA services
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
CRL tree already moved
[Verifying that CA proxy configuration is correct]
[Verifying that KDC configuration is using ipa-kdb backend]
[Fix DS schema file syntax]
Syntax already fixed
[Removing RA cert from DS NSS database]
RA cert already removed
[Enable sidgen and extdom plugins by default]
[Updating HTTPD service IPA configuration]
[Updating mod_nss protocol versions]
Protocol versions already updated
[Updating mod_nss cipher suite]
[Fixing trust flags in /etc/httpd/alias]
Trust flags already processed
[Exporting KRA agent PEM file]
KRA is not enabled
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
CalledProcessError: Command '/bin/systemctl start httpd.service'
returned non-zero exit status 1
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
more information/

These are error logs of Apache:
/[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] AH01232:
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664]
NSSSessionCacheTimeout is deprecated. Ignoring.
[Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] Certificate not
found: 'Server-Cert'/

The problem seems to be the /Server-Cert /that could not be found.
But if I try to execute the certutil command manually I can see it:/
[root@mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/
Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  Pu,u,u
IPA.MYDOMAIN.COM  IPA
CACT,C,C/

Could you help me?
What could I try to do to restart my service?


Hi,

I would first make sure that httpd is using /etc/httpd/alias as NSS DB 
(check the directive NSSCertificateDatabase in /etc/httpd/conf.d/nss.conf).
Then it may be a file permission issue: the NSS DB should belong to 
root:apache (the relevant files are cert8.db, key3.db and secmod.db).
You should also find a pwdfile.txt in the same directory, containing the 
NSS DB password. Check that the password is valid using

certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt
(if the command succeeds then the password in pwdfile is OK).

You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by setting 
"LogLevel debug", and check the output in /var/log/httpd/error_log.


HTH,
Flo.

Thanks, Morgan




--
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] My IPA installation doesn't work after upgrade

[Florence Blanc-Renaud]

debug] [pid 10660]
> nss_engine_init.c(1077): NSSCipherSuite:  Configuring permitted SSL
> ciphers
> 
[+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha]
> [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660]
> [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname
> Server-Cert.
[snip]
> [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate not
> found: 'Server-Cert'

Can you shows what this returns:

# grep NSSNickname /etc/httpd/conf.d/nss.conf

> Do you think there is a kerberos problem?

It definitely is not.

You can bring the system up in a minimal way by manually starting the
dir...@example.com <mailto:dir...@example.com> service and then
krb5kdc. This will at least let your
users authenticate. The management framework (GUI) runs through Apache
so that will be down until we can get Apache started again.

rob

>
> Please let me know, thanks.
> Bye, Morgan
>
> 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com 
<mailto:f...@redhat.com>
> <mailto:f...@redhat.com <mailto:f...@redhat.com>>>:
>
> On 11/17/2016 12:09 PM, Morgan Marodin wrote:
>
> Hello.
>
> This morning I've tried to upgrade my IPA server, but the
upgrade
> failed, and now the service doesn't start! :(
>
> If I try lo launch the upgrade manually this is the output:
> /[root@mlv-ipa01 download]# ipa-server-upgrade
>
> Upgrading IPA:
>   [1/8]: saving configuration
>   [2/8]: disabling listeners
>   [3/8]: enabling DS global lock
>   [4/8]: starting directory server
>   [5/8]: updating schema
>   [6/8]: upgrading server
>   [7/8]: stopping directory server
>   [8/8]: restoring configuration
> Done.
> Update complete
> Upgrading IPA services
> Upgrading the configuration of the IPA services
> [Verifying that root certificate is published]
> [Migrate CRL publish directory]
> CRL tree already moved
> [Verifying that CA proxy configuration is correct]
> [Verifying that KDC configuration is using ipa-kdb backend]
> [Fix DS schema file syntax]
> Syntax already fixed
> [Removing RA cert from DS NSS database]
> RA cert already removed
> [Enable sidgen and extdom plugins by default]
> [Updating HTTPD service IPA configuration]
> [Updating mod_nss protocol versions]
> Protocol versions already updated
> [Updating mod_nss cipher suite]
> [Fixing trust flags in /etc/httpd/alias]
> Trust flags already processed
> [Exporting KRA agent PEM file]
> KRA is not enabled
> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log
and run
> command ipa-server-upgrade manually.
> Unexpected error - see /var/log/ipaupgrade.log for details:
> CalledProcessError: Command '/bin/systemctl start
httpd.service'
> returned non-zero exit status 1
> The ipa-server-upgrade command failed. See
> /var/log/ipaupgrade.log for
> more information/
>
> These are error logs of Apache:
> /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664]
> AH01232:
> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664]
> NSSSessionCacheTimeout is deprecated. Ignoring.
> [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664]
> Certificate not
> found: 'Server-Cert'/
>
> The problem seems to be the /Server-Cert /that could not
be found.
> But if I try to execute the certutil command manually I
can see it:/
> [root@mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/
> Certificate Nickname
   Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
> Signing-Cert
   u,u,u
> ipaCert
  u,u,u
> Server-Cert
  Pu,u,u
> IPA.MYDOMAIN.COM 

Re: [Freeipa-users] My IPA installation doesn't work after upgrade

[Florence Blanc-Renaud]

ssword -LLL -b 
krbprincipalname=HTTP/ipaserver.ipadomain@IPADOMAIN,cn=services,cn=accounts,dc=IPADOMAIN


The cert will be stored in the field "usercertificate".

HTH,
Flo.


Please let me know, thanks.
Bye, Morgan

2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>>:

On 11/17/2016 04:51 PM, Morgan Marodin wrote:

Hi Rob.

I've just tried to remove the group write to the *.db files, but
it's
not the problem.
/[root@mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf
NSSNickname Server-Cert/

I've tried to run manually /dirsrv.target/ and
/krb5kdc.service/, and it
works, services went up.
The same for /ntpd/, /named-pkcs11.service/, /smb.service/,
/winbind.service/, /kadmin.service/, /memcached.service/ and
/pki-tomcatd.target/.

But if I try to start /httpd.service/:
/[root@mlv-ipa01 ~]# tail -f /var/log/messages
Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP
Server...
Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa :
INFO KDC
proxy enabled
Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process
exited, code=exited, status=1/FAILURE
Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process ""
Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control process
exited, code=exited status=1
Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache
HTTP
Server.
Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered
failed
state.
Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./

Any other ideas?

Hi,

- Does the NSS Db contain the private key for Server-Cert? If yes,
the command
$ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt
should display a line like this one:
< 0> rsa  01a6cbd773f3d785ffa44233148dcb8ade266ea5   NSS
Certificate DB:Server-Cert

- Is your system running with SElinux enforcing? If yes, you can
check if there were SElinux permission denials using
$ ausearch -m avc --start recent

- If the certificate was expired, I believe you would see a
different message, but it doesn't hurt to check its validity
$ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not
Before|Not After"


Flo.


Please let me know, thanks.
Morgan

2016-11-17 16:11 GMT+01:00 Rob Crittenden <rcrit...@redhat.com
<mailto:rcrit...@redhat.com>
<mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>>:


Morgan Marodin wrote:
> Hi Florence.
>
> Thanks for your support.
>
> Yes, httpd is using /etc/httpd/alias as NSS DB. And seems
that all
> permissions and certificates are good:
> /[root@mlv-ipa01 ~]# ls -l /etc/httpd/alias/
> total 184
> -r--r--r--  1 root root1345 Sep  7  2015 cacert.asc
> -rw-rw  1 root apache 65536 Nov 17 11:06 cert8.db
> -rw-r-. 1 root apache 65536 Sep  4  2015 cert8.db.orig
> -rw---. 1 root root4833 Sep  4  2015 install.log
> -rw-rw  1 root apache 16384 Nov 17 11:06 key3.db
> -rw-r-. 1 root apache 16384 Sep  4  2015 key3.db.orig
> lrwxrwxrwx  1 root root  24 Nov 17 10:24 libnssckbi.so ->
> /usr/lib64/libnssckbi.so
> -rw-rw  1 root apache20 Sep  7  2015 pwdfile.txt
> -rw-rw  1 root apache 16384 Sep  7  2015 secmod.db
> -rw-r-. 1 root apache 16384 Sep  4  2015 secmod.db.orig/

Eventually you'll want to remove group write on the *.db files.

> And password validations seems ok, too:
> /[root@mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f
> /etc/httpd/alias/pwdfile.txt
good

> Enabling mod-nss debug I can see these logs:
> /[root@mlv-ipa01 ~]# tail -f /var/log/httpd/error_log
> [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid
10660] AH01232:
> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660]
> NSSSessionCacheTimeout is deprecated. Ignoring.
> [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660]
> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com
<http://mlv-ipa01.ipa.mydomain.com>
<http://mlv-ipa01.ipa.mydomain.com
<http://mlv-ipa01.ipa.mydomain.com>>
> <http://mlv

Re: [Freeipa-users] Password Complexity Requirements Seems Insufficient

[Florence Blanc-Renaud]

On 10/11/2016 07:36 PM, Bennett, Chip wrote:

I just joined this list, so if this question has been asked before (and
I’ll bet it has), I apologize in advance.



A google search was unrevealing, so I’m asking here: we’re running
FreeIPA Version 3.0.0 on CentOS 6.6.   It looks like the password
complexity requirements are limited to setting the number of character
classes to require, i.e. setting it to “2” would require your new
password to be any two of the character classes.



What if you wanted new passwords to meet specific class requirements,
i.e. a mix of UL, LC, and numbers.  It looks like you would use a value
of “3” to accomplish this, but that would also allow UC, LC, and
special, or LC, numbers, and special, but you don’t want to allow the
those:  how would you specify that?


Hi,

as far as I know, it is only possible to specify the number of different 
character classes. The doc chapter "Creating Password Policies in the 
Web UI" [1] describes the following:

---
Character classes sets the number of different categories of character 
that must be used in the password. This does not set which classes must 
be used; it sets the number of different (unspecified) classes which 
must be used in a password. For example, a character class can be a 
number, special character, or capital; the complete list of categories 
is in Table 22.1, “Password Policy Settings”. This is part of setting 
the complexity requirements.

---

hope this clarifies,
Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Setting_Different_Password_Policies_for_Different_User_Groups.html#creating-group-policy-ui






Also, what if you had a requirement for more than one of the character
classes, i.e. you want to require two UC characters or two special
characters?



Thanks in advance for the help,

Chip Bennett




This message is solely for the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited.  ­­




--
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-install failing, dirsrv not starting properly during install process

[Florence Blanc-Renaud]

On 11/29/2016 03:19 PM, David Dejaeghere wrote:

Can you give me a couple of test commands?
I am not familiar with Dogtag.


Hi,

To reproduce the issue:
1. install IPA server
2. On the replica, run ipa-client-install
3. On the server, stop dogtag with
$ systemctl stop pki-tomcatd@pki-tomcat.service
4. On the replica, run ipa-replica-install

When you want to restart dogtag, you can run
$ systemctl start pki-tomcatd@pki-tomcat.service

If you want to check if dogtag is running:
$ systemctl status pki-tomcatd@pki-tomcat.service

You may find more information on Dogtag here:
http://pki.fedoraproject.org/wiki/PKI_Main_Page
http://pki.fedoraproject.org/wiki/IPA
http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dogtag_in_an_ipa_install

Flo


Groeten,

David

2016-11-29 14:57 GMT+01:00 David Kupka >:

On 29/11/16 13:55, David Dejaeghere wrote:

Correct.  Same symptoms.

2016-11-29T10:29:42Z DEBUG certmonger request is in state
dbus.String(u'CA_UNREACHABLE', variant_level=1)

Fedora 24 Server

[root@ns02 ~]# dnf history userinstalled
Packages installed by user
freeipa-client-4.3.2-2.fc24.x86_64
freeipa-server-4.3.2-2.fc24.x86_64
grub2-1:2.02-0.34.fc24.x86_64
kernel-4.5.5-300.fc24.x86_64
kernel-4.8.8-200.fc24.x86_64
lvm2-2.02.150-2.fc24.x86_64
xfsprogs-4.5.0-2.fc24.x86_64


Ok. I've reproduced it by simply stopping dogtag on FreeIPA server
while installing the replica. I see the exactly same errors as
you've reported and are described in the ticket, now.

Is dogtag running on your master? Is in responding (e.g. issuing
certificates for users)? Is it accessible from the replica?



2016-11-29 13:41 GMT+01:00 Petr Vobornik >:

On 11/29/2016 12:43 PM, David Kupka wrote:

On 29/11/16 12:15, David Dejaeghere wrote:

Seems like it is but it does not show a server cert
for dirsrv

[root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/
total 468
-rw---. 1 dirsrv root
 unconfined_u:object_r:dirsrv_config_t:s0
65536
Nov 29 11:29 cert8.db
-rw-rw. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
65536
Nov 29 11:29 cert8.db.orig
-r--r-. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
1623
Nov 29 11:29 certmap.conf
-rw---. 1 dirsrv dirsrv
system_u:object_r:dirsrv_config_t:s0
89977
Nov 29 11:29 dse.ldif
-rw---. 2 dirsrv dirsrv
system_u:object_r:dirsrv_config_t:s0
89977
Nov 29 11:29 dse.ldif.bak
-rw---. 2 dirsrv dirsrv
system_u:object_r:dirsrv_config_t:s0
89977
Nov 29 11:29 dse.ldif.startOK
-r--r-. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
36228
Nov 29 11:28 dse_original.ldif
-rw---. 1 dirsrv root
 unconfined_u:object_r:dirsrv_config_t:s0
16384
Nov 29 11:29 key3.db
-rw-rw. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
16384
Nov 29 11:29 key3.db.orig
-r. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s066
Nov 29 11:29 pin.txt
-rw---. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s040
Nov 29 11:29 pwdfile.txt
drwxrwx---. 2 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
4096
Nov 29 11:29 schema
-rw---. 1 dirsrv root
 unconfined_u:object_r:dirsrv_config_t:s0
16384
Nov 29 11:29 secmod.db
-rw-rw. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
16384
Nov 29 11:29 secmod.db.orig
-r--r-. 1 dirsrv dirsrv
unconfined_u:object_r:dirsrv_config_t:s0
15142
Nov 29 11:28 slapd-collations.conf

[root@ns02 ~]# certutil -d
/etc/dirsrv/slapd-SOMETHING-BE -L

Re: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[Florence Blanc-Renaud]

On 12/12/2016 10:32 PM, jay wrote:

Hello,

I have been testing freeipa on CentOS 7 for a while now with a
relatively simple setup, just a single server and 12 or so Linux clients
in AWS.  I went to rebuild the environment today and part of my Ansible
playbook failed with this error

ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)

This is the command that failed

/usr/bin/ipa cert-show 1 --out=/root/cacert.crt

I noticed the version I was using on Friday was
ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64.  But now I'm getting
ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated
over the weekend.

Is there a known issue running cert-show with this version?  I can't
find anything in the debug logs that point to something wrong.  Running
'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work
just fine.

Can someone offer some advice or pointer to what might be going on?  I'm
invoking the install with these options and it has worked flawlessly
before this new version

2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments
[] and options: {'no_dns_
sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False,
'ip_addresses': [CheckedIPAddr
ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None,
'http_cert_files': None, 'no_ntp': N
one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type':
None, 'ssh_trust_dns': True
, 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None,
'http_cert_name': None, 'dirsrv_
cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm':
None, 'no_reverse': None,
 'subject': None, 'unattended': True, 'auto_reverse': None,
'auto_forwarders': None, 'no_host_dns'
: None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role':
None, 'realm_name': 'IPA.U
S-WEST-2.COMPUTE.INTERNAL', 'forwarders':
[CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte
rnal_ca': None, 'no_ssh': None, 'external_cert_files': None,
'no_hbac_allow': None, 'forward_polic
y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr':
None, 'quiet': False, 'setup
_dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal',
'dirsrv_config_file': None
, 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False}
2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos

Thank you
Jay




Hi,

the ipa cert-show command is communicating with Dogtag, using port 443. 
Can you check if Dogtag is properly responding on this port?


$ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat 
/etc/httpd/alias/pwdfile.txt` 
https://hostname.domainname:443/ca/agent/ca/displayBySerial?serialNumber=1 
-o out.html


The issue can be that Dogtag is down, or a SSL issue (the certificate 
ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag).


HTH,
Flo.

--
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] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[Florence Blanc-Renaud]

On 12/13/2016 05:29 PM, jay wrote:

Well Flo, the issue was IPV6 was disabled.  As soon as I enabled it
again, added that /etc/hosts entry back, and rebooted the server, things
are working again!

So is that now a requirement for 4.4.x?  Server worked fine on 4.2

Hi Jay,

this behavior was introduced with the fix for ticket 4291 (CA not start 
during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 [1].


I agree that the doc [2] does not explicitely mention that IPv6 is 
required, but it sort of suggests that it should be set up.


I found an e-mail thread mentioning why IPv6 should not be disabled [3], 
and also on freeipa.org a wiki for Deployment recommendations [4].


I will open a documentation bug asking to add this requirement in Red 
Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy 
Guide.


Flo

[1] https://fedorahosted.org/freeipa/ticket/4291
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
[3] 
https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html
[4] 
http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration



without IPV6 enabled.  Or has that always been a requirement and I just
got lucky somehow.  I'm looking through the docs now.

Regardless, thank you very much for the help Flo!

Jay

On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 12/13/2016 04:41 PM, jay wrote:

Maybe this will help more, I noticed this error in the Apache logs

[Tue Dec 13 09:33:37.774921 2016 <tel:774921%202016>] [:error]
[pid 2309] ipa: INFO:
[jsonserver_kerb] ad...@ipa.us-west-2.compute.in
<mailto:ad...@ipa.us-west-2.compute.in>TERNAL:
cert_show/1(u'1', version=u'2.213'): CertificateOperationError
[Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316]
(111)Connection refused: AH00957: AJP: attempt to connect to
127.0.0.1:8009 <http://127.0.0.1:8009> <http://127.0.0.1:8009>
(localhost) failed
[Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316]
[client
172.31.0.254:39646 <http://172.31.0.254:39646>
<http://172.31.0.254:39646>] AH00896: failed to make
connection to backend: localhost
[Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
ra.get_certificate(): Unable to communicate with CMS (503)


So whatever is running on port 8009 isn't responding or setup
properly.

Jay

On Tue, Dec 13, 2016 at 8:46 AM, jay <titleistf...@gmail.com
<mailto:titleistf...@gmail.com>
<mailto:titleistf...@gmail.com <mailto:titleistf...@gmail.com>>>
wrote:

Thank you for the response Flo.  So I do see Apache running and
listening on port 443.  However, running that command I get
a 503

*   Trying 172.31.0.254...
* Connected to ip-172-31-0-254.us-west-2.compute.internal
(172.31.0.254) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/httpd/alias
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject:


CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:33:16 2016 GMT
*   expire date: Dec 14 14:33:16 2018 GMT
*   common name: ip-172-31-0-254.us-west-2.compute.internal
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ip-172-31-0-254.us-west-2.compute.internal
> Accept: */*
>
* NSS: using client certificate: ipaCert
*   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INT
<http://IPA.US-WEST-2.COMPUTE.INT>ERNAL
*   start date: Dec 13 14:32:28 2016 GMT
*   expire date: Dec 03 14:32:28 2018 GMT
*   common name: IPA RA
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
< HTTP/1.1 503 Service Unavailable
< Date: Tue, 13 Dec 2016 14:44:00 GMT
< Server: Apache
< Content-Length: 299
< Connection: close
< Content-Type: text/html; charset=iso-8859-1

 

Re: [Freeipa-users] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/14/2016 01:08 PM, beeth beeth wrote:

Thanks David. I installed both the master and replica IPA servers with
third-party certificates(Verisign), but I doubt that could be the issue,
because I had no problem to run the same ipa-client-install command on a
RHEL7 machine(of course, the --hostname used a different hostname of the
server). And I had no problem to run the ipa-client-install command with
--server= on such RHEL6 machine. So what could cause the LDAP
communication failed during the client enrollment with the replica? Is
there a way I can troubleshoot this by running some commands? So far I
did telnet to check the open ports, as well as run the ldapsearch
towards the replica. Thanks again!


On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > wrote:

On 13/12/16 05:44, beeth beeth wrote:

I have two IPA servers ipaprd1.example.com
 and ipaprd2.example.com
, running
ipa 4.4 on RHEL7. When I tried to install/configure the client
on a RHEL6
system(called ipadev6), I had issue when I tried to enroll it
with the
replica(ipaprd2), while no issue with the primary(ipaprd1):

# ipa-client-install --domain=ipa.example.com
 --server=ipaprd1.example.com

--server=ipaprd2.example.com 
--hostname=ipadev6.example.com 
LDAP Error: Protocol error: unsupported extended operation
Autodiscovery of servers for failover cannot work with this
configuration.
If you proceed with the installation, services will be
configured to always
access the discovered server for all operations and will not
fail over to
other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]

Then I tried to run ipa-client-install to enroll with the
replica(ipaprd2),
with debug mode, I got this:

# ipa-client-install --domain=ipa.example.com
 --server=ipaprd2.example.com

 --hostname=ipadev6.example.com  -d
/usr/sbin/ipa-client-install was invoked with options: {'domain': '
ipa.example.com ', 'force': False,
'realm_name': None,
'krb5_offline_passwords': True, 'primary': False, 'mkhomedir':
False,
'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True,
'on_master':
False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False,
'principal': None, 'hostname': 'ipadev6.example.com
', 'no_ac': False,
'unattended': None, 'sssd': True, 'trust_sshfp': False,
'kinit_attempts':
5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True,
'force_join':
False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com
'],
'prompt_password': False, 'permit': False, 'debug': True,
'preserve_sssd':
False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=ipa.example.com
, servers=['
ipaprd2.example.com '],
hostname=ipadev6.example.com 
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of _kerberos.ipa.example.com
.
No DNS record found
Search DNS for SRV record of _kerberos._udp.ipa.example.com
.
No DNS record found
SRV record for KDC not found! Domain: ipa.example.com

[LDAP server check]
Verifying that ipaprd2.example.com 
(realm None) is an IPA server
Init LDAP connection with: ldap://ipaprd2.example.com:389

LDAP Error: Protocol error: unsupported extended operation
Discovery result: UNKNOWN_ERROR; server=None,
domain=ipa.example.com ,
kdc=None, basedn=None
Validated servers:
will use discovered domain: ipa.example.com 
IPA Server not found
[IPA Discovery]
Starting IPA discovery with domain=ipa.example.com
, servers=['
ipaprd2.example.com 

Re: [Freeipa-users] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/14/2016 07:49 PM, beeth beeth wrote:

Hi Flo,

Thanks for the great hint! I reran the ipa-client-install on the rhel6
box(ipadev6), and monitored the access log file you mentioned on the
replica:

# ipa-client-install --domain=ipa.example.com <http://ipa.example.com>
--server=ipaprd2.example.com <http://ipaprd2.example.com>
 --hostname=ipadev6.example.com <http://ipadev6.example.com> -d

( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on RHEL6 )

AFTER about 3 seconds, I saw these on the replica ipaprd2:
[14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73
connection from  to 
[14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND
[14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 closed - U1
[14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73
connection from  to 
[14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND
[14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 closed - U1
[14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND
[14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 closed - U1

So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I checked the
oid and got:

1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511)

It looked to be related with TLS... pease advise. Thanks!



Hi,

when the replica got installed, the installer must have configured the 
directory server for SSL and start TLS. I tend to suspect an expired 
certificate issue rather than a misconfiguration. Could you please check 
that dirsrv certificate is still valid?


$ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not
Not Before: Wed Dec 14 16:56:02 2016
Not After : Sat Dec 15 16:56:02 2018

If the certificate is still valid, you may want to read 389-ds How-To to 
make sure that SSL is properly setup:

http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings

Flo.



On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 12/14/2016 01:08 PM, beeth beeth wrote:

Thanks David. I installed both the master and replica IPA
servers with
third-party certificates(Verisign), but I doubt that could be
the issue,
because I had no problem to run the same ipa-client-install
command on a
RHEL7 machine(of course, the --hostname used a different
hostname of the
server). And I had no problem to run the ipa-client-install
command with
--server= on such RHEL6 machine. So what could cause the
LDAP
communication failed during the client enrollment with the
replica? Is
there a way I can troubleshoot this by running some commands? So
far I
did telnet to check the open ports, as well as run the ldapsearch
towards the replica. Thanks again!


On Tue, Dec 13, 2016 at 8:46 AM, David Kupka <dku...@redhat.com
<mailto:dku...@redhat.com>
<mailto:dku...@redhat.com <mailto:dku...@redhat.com>>> wrote:

On 13/12/16 05:44, beeth beeth wrote:

I have two IPA servers ipaprd1.example.com
<http://ipaprd1.example.com>
<http://ipaprd1.example.com> and ipaprd2.example.com
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>, running
ipa 4.4 on RHEL7. When I tried to install/configure the
client
on a RHEL6
system(called ipadev6), I had issue when I tried to
enroll it
with the
replica(ipaprd2), while no issue with the primary(ipaprd1):

# ipa-client-install --domain=ipa.example.com
<http://ipa.example.com>
<http://ipa.example.com> --server=ipaprd1.example.com
<http://ipaprd1.example.com>
<http://ipaprd1.example.com>
--server=ipaprd2.example.com
<http://ipaprd2.example.com> <http://ipaprd2.example.com>
--hostname=ipadev6.example.com
<http://ipadev6.example.com> <http://ipadev6.example.com>
LDAP Error: Protocol error: unsupported extended operation
Autodiscovery of servers for failover cannot work with this
configuration.
If you proceed with the installation, services will be
configured to always
access 

Re: [Freeipa-users] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

ar/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests
[15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning:
no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning:
no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for
cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting
domain/map/id
"cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com")
[15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning:
no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished
plugin initialization.
[15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin -
ipa_topo_util_get_replica_conf: server configuration missing
[15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin -
ipa_topo_util_get_replica_conf: cannot create replica

Any idea?
BTW, everything ran well on IPA 4.2(server installation and client
installation), as you once assisted me couple months ago, until we set
up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA
version changed from 4.2 to 4.4. Last time you guided me about the
change since IPA 4.3, for the newly introduced domain level concept, and
the way how the replica should be installed was changed too... Thanks again!


Hi Beeth,

I managed to reproduce your issue with IPA master installed without dns 
and without integrated CA.


Can you check on your RHEL 6 client if there is a file /etc/ipa/ca.crt? 
If yes, check its content with

$ sudo openssl x509 -noout -text -in /etc/ipa/ca.crt
and compare with the CA certificate stored on the master or the replica 
(at the same location /etc/ipa/ca.crt). The certificate should be the 
one for the CA that signed your HTTPd and LDAP server certs (ie Verisign).


If the certificate is different, it is probably a left-over CA 
certificate corresponding to a previous installation. You can just 
delete the file on the client and re-run ipa-client-install.


Flo.



On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 12/14/2016 07:49 PM, beeth beeth wrote:

Hi Flo,

Thanks for the great hint! I reran the ipa-client-install on the
rhel6
box(ipadev6), and monitored the access log file you mentioned on the
replica:

# ipa-client-install --domain=ipa.example.com
<http://ipa.example.com> <http://ipa.example.com>
--server=ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
 --hostname=ipadev6.example.com <http://ipadev6.example.com>
<http://ipadev6.example.com> -d

( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on
RHEL6 )

AFTER about 3 seconds, I saw these on the replica ipaprd2:
[14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73
connection from  to 
[14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND
[14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73
closed - U1
[14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73
connection from  to 
[14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND
[14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73
closed - U1
[14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND
[14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66
closed - U1

So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I
checked the
oid and got:

1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511)

It looked to be related with TLS... pease advise. Thanks!


Hi,

when the replica got installed, the installer must have configured
the directory server for SSL and start TLS. I tend to suspect an
expired certificate issue rather than a misconfiguration. Could you
please check that dirsrv certificate is still valid?

$ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not
Not Before: Wed Dec 14 16:56:02 2016
Not After : Sat Dec 15 16:56:02 2018

If the certificate is still valid, you may want to 

Re: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[Florence Blanc-Renaud]

On 12/13/2016 04:41 PM, jay wrote:

Maybe this will help more, I noticed this error in the Apache logs

[Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO:
[jsonserver_kerb] ad...@ipa.us-WEST-2.COMPUTE.INTERNAL:
cert_show/1(u'1', version=u'2.213'): CertificateOperationError
[Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316]
(111)Connection refused: AH00957: AJP: attempt to connect to
127.0.0.1:8009 <http://127.0.0.1:8009> (localhost) failed
[Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client
172.31.0.254:39646 <http://172.31.0.254:39646>] AH00896: failed to make
connection to backend: localhost
[Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
ra.get_certificate(): Unable to communicate with CMS (503)


So whatever is running on port 8009 isn't responding or setup properly.

Jay

On Tue, Dec 13, 2016 at 8:46 AM, jay <titleistf...@gmail.com
<mailto:titleistf...@gmail.com>> wrote:

Thank you for the response Flo.  So I do see Apache running and
listening on port 443.  However, running that command I get a 503

*   Trying 172.31.0.254...
* Connected to ip-172-31-0-254.us-west-2.compute.internal
(172.31.0.254) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/httpd/alias
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject:

CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:33:16 2016 GMT
*   expire date: Dec 14 14:33:16 2018 GMT
*   common name: ip-172-31-0-254.us-west-2.compute.internal
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ip-172-31-0-254.us-west-2.compute.internal
> Accept: */*
>
* NSS: using client certificate: ipaCert
*   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:32:28 2016 GMT
*   expire date: Dec 03 14:32:28 2018 GMT
*   common name: IPA RA
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
< HTTP/1.1 503 Service Unavailable
< Date: Tue, 13 Dec 2016 14:44:00 GMT
< Server: Apache
< Content-Length: 299
< Connection: close
< Content-Type: text/html; charset=iso-8859-1

[root@ip-172-31-0-254 ~]# cat out.html


503 Service Unavailable

Service Unavailable
The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.

[root@ip-172-31-0-254 ~]#


What would cause the service to be unavailable?  Maybe the installer
changed and I need to provide another option now that I didn't have
to before the version upgrade?


Hi Jay,

I am not completely familiar with Tomcat, but I understand so far that 
the httpd server is configured to redirect requests on displayBySerial 
to Tomcat with this setting in the file 
/etc/httpd/conf.d/ipa-pki-proxy.conf:


"^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector">

NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
NSSVerifyClient require
ProxyPassMatch ajp://localhost:8009
ProxyPassReverse ajp://localhost:8009


And this port must be configured in /etc/pki/pki-tomcat/server.xml:


In my setup I also have /etc/hosts defining localhost:
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 
localhost6.localdomain6



Can you check that you also have those settings? If yes, then I assume 
that Tomcat is not able to create the AJP connector on port 8009.
When PKI is started, you should find a trace of the connector 
initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log:


12-Dec-2016 13:54:17.579 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["ajp-nio-0:0:0:0:0:0:0:1-8009"]
12-Dec-2016 13:54:25.076 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["ajp-nio-0:0:0:0:0:0:0:1-8009"]
12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] 
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication 
RESTEASY002225: Deploying javax.ws.rs.core.Application: class 
org.dogtagpki.server.ca.rest.CAApplication


Next steps to debug would be to increase Tomcat logs.
Flo.



Thanks,
Jay

On Tue, Dec 13, 2016 at 1:56 AM, 

Re: [Freeipa-users] Switch certificates from external CA to internal

[Florence Blanc-Renaud]

On 01/12/2017 02:57 PM, Jeff Goddard wrote:

I've had issues with expired certificates. In the course of
troubleshooting I've somehow set the cas to external. Is there a way I
can switch back?

[root@id-management-1 conf]# getcert list-cas
CA 'SelfSign':
is-default: no
ca-type: INTERNAL:SELF
next-serial-number: 01
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/ipa-submit
CA 'certmaster':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/certmaster-submit
CA 'dogtag-ipa-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit
CA 'local':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/local-submit
CA 'dogtag-ipa-ca-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location:
/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit -vv

Thanks,

Jeff




Hi Jeff,

the following documentation explains how to change the certificate chain 
from externally-signed to self-signed:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html

HTH,
Flo.

--
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-install failing, dirsrv not starting properly during install process

[Florence Blanc-Renaud]

On 11/30/2016 03:27 PM, David Dejaeghere wrote:

Hi,

The Pki service is running and I cannot find any issues with it.  I can
run a curl request to the master hostname on port 8443 and communication
works fine.
Any other idea why this replica install code would fail and log
CA_UNREACHABLE?


Hi,

can you check the logs on the server around the time of the replica 
installation?

- in /var/log/httpd/access_log you should find a line with
"POST https://ipaserver.domain.com:443/ca/eeca/ca/profileSubmitSSLClient 
HTTP/1.1" 200 2216


This line shows that certmonger did send the certificate request to IPA 
master.

- in /var/log/httpd/error_log, around the same time, you may find
[proxy:error] [pid 20702] (111)Connection refused: AH00957: AJP: attempt 
to connect to 127.0.0.1:8009 (localhost) failed
[proxy:error] [pid 20702] AH00959: ap_proxy_connect_backend disabling 
worker for (localhost) for 60s
[proxy_ajp:error] [pid 20702] [client ] AH00896: failed to 
make connection to backend: localhost
[:error] [pid 20698] ipa: ERROR: ra.request_certificate(): Unable to 
communicate with CMS (503)
[:error] [pid 20698] ipa: INFO: [xmlserver] 
host/ipasrerver.domain@domain.com: cert_request(u'[...]', 
principal=u'ldap/ipaclient.domain@domain.com', add=True, 
version=u'2.51'): CertificateOperationError


If you find this type of error, the problem may come from the 
redirection httpd -> tomcat.
Apache is configured to redirect the URL profileSubmitSSLClient to 
ajp://localhost:8009 (see in /etc/httpd/conf.d/ipa-pki-proxy.conf).


You can check if Dogtag is listening on port 8009 (with netstat -tupnl | 
grep 8009, which should output the pid of Dogtag). If it is not the 
case, there is probably a configuration issue on Tomcat side.


Flo.


Regards,

David


2016-11-29 22:16 GMT+01:00 Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>>:

On 11/29/2016 03:19 PM, David Dejaeghere wrote:

Can you give me a couple of test commands?
I am not familiar with Dogtag.

Hi,

To reproduce the issue:
1. install IPA server
2. On the replica, run ipa-client-install
3. On the server, stop dogtag with
$ systemctl stop pki-tomcatd@pki-tomcat.service
4. On the replica, run ipa-replica-install

When you want to restart dogtag, you can run
$ systemctl start pki-tomcatd@pki-tomcat.service

If you want to check if dogtag is running:
$ systemctl status pki-tomcatd@pki-tomcat.service

You may find more information on Dogtag here:
http://pki.fedoraproject.org/wiki/PKI_Main_Page
<http://pki.fedoraproject.org/wiki/PKI_Main_Page>
http://pki.fedoraproject.org/wiki/IPA
<http://pki.fedoraproject.org/wiki/IPA>

http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dogtag_in_an_ipa_install

<http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dogtag_in_an_ipa_install>

Flo

Groeten,

David

2016-11-29 14:57 GMT+01:00 David Kupka <dku...@redhat.com
<mailto:dku...@redhat.com>
<mailto:dku...@redhat.com <mailto:dku...@redhat.com>>>:

On 29/11/16 13:55, David Dejaeghere wrote:

Correct.  Same symptoms.

2016-11-29T10:29:42Z DEBUG certmonger request is in state
dbus.String(u'CA_UNREACHABLE', variant_level=1)

Fedora 24 Server

[root@ns02 ~]# dnf history userinstalled
Packages installed by user
freeipa-client-4.3.2-2.fc24.x86_64
freeipa-server-4.3.2-2.fc24.x86_64
grub2-1:2.02-0.34.fc24.x86_64
kernel-4.5.5-300.fc24.x86_64
kernel-4.8.8-200.fc24.x86_64
lvm2-2.02.150-2.fc24.x86_64
xfsprogs-4.5.0-2.fc24.x86_64


Ok. I've reproduced it by simply stopping dogtag on FreeIPA
server
while installing the replica. I see the exactly same errors as
you've reported and are described in the ticket, now.

Is dogtag running on your master? Is in responding (e.g. issuing
certificates for users)? Is it accessible from the replica?



2016-11-29 13:41 GMT+01:00 Petr Vobornik
<pvobo...@redhat.com <mailto:pvobo...@redhat.com>
<mailto:pvobo...@redhat.com <mailto:pvobo...@redhat.com>>>:


On 11/29/2016 12:43 PM, David Kupka wrote:

On 29/11/16 12:15, David Dejaeghere wrote:

Seems like it is but it does not show a
server cert
for dirsrv

[root@ns02 ~]# ls -lZ
/etc/dirsrv/slapd-SOMETHING-BE/
total 468
-rw---. 1 dirsrv root
 unconfined_u:object_r:dirsrv_conf

Re: [Freeipa-users] Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA

[Florence Blanc-Renaud]

On 12/05/2016 08:15 PM, Robert Kudyba wrote:

Are there instructions to manually uninstall? I’m getting the below errors.

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 ~]# cat /var/log/ipaserver-uninstall.log
2016-12-05T19:13:45Z DEBUG Logging to /var/log/ipaserver-uninstall.log
2016-12-05T19:13:45Z DEBUG ipa-server-install was invoked with arguments
[] and options: {'no_dns_sshfp': None, 'ignore_topology_disconnect':
None, 'verbose': False, 'ip_addresses': None, 'domainlevel': None,
'mkhomedir': None, 'no_pkinit': None, 'http_cert_files': None, 'no_ntp':
None, 'subject': None, 'no_forwarders': None, 'external_ca_type': None,
'ssh_trust_dns': None, 'domain_name': None, 'idmax': None,
'http_cert_name': None, 'dirsrv_cert_files': None,
'no_dnssec_validation': None, 'ca_signing_algorithm': None,
'no_reverse': None, 'pkinit_cert_files': None, 'unattended': True,
'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None,
'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': None,
'realm_name': None, 'forwarders': None, 'idstart': None, 'external_ca':
None, 'pkinit_cert_name': None, 'no_ssh': None, 'external_cert_files':
None, 'no_hbac_allow': None, 'forward_policy': None, 'dirsrv_cert_name':
None, 'ca_cert_files': None, 'zonemgr': None, 'quiet': False,
'setup_dns': None, 'host_name': None, 'dirsrv_config_file': None,
'log_file': None, 'reverse_zones': None, 'allow_zone_overlap': None,
'uninstall': True}
2016-12-05T19:13:45Z DEBUG IPA version 4.4.2-1.fc25
2016-12-05T19:13:45Z DEBUG Starting external process
2016-12-05T19:13:45Z DEBUG args=/usr/sbin/selinuxenabled
2016-12-05T19:13:45Z DEBUG Process finished, return code=0
2016-12-05T19:13:45Z DEBUG stdout=
2016-12-05T19:13:45Z DEBUG stderr=
2016-12-05T19:13:45Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-12-05T19:13:45Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2016-12-05T19:13:45Z DEBUG httpd is configured
2016-12-05T19:13:45Z DEBUG kadmin is configured
2016-12-05T19:13:45Z DEBUG dirsrv is configured
2016-12-05T19:13:45Z DEBUG pki-tomcatd is configured
2016-12-05T19:13:45Z DEBUG install is not configured
2016-12-05T19:13:45Z DEBUG krb5kdc is configured
2016-12-05T19:13:45Z DEBUG ntpd is configured
2016-12-05T19:13:45Z DEBUG named is not configured
2016-12-05T19:13:45Z DEBUG ipa_memcached is configured
2016-12-05T19:13:45Z DEBUG filestore has files
2016-12-05T19:13:45Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2016-12-05T19:13:45Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2016-12-05T19:13:45Z DEBUG importing all plugin modules in
ipaserver.plugins...
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.aci
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.automember
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.automount
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.baseldap
2016-12-05T19:13:45Z DEBUG ipaserver.plugins.baseldap is not a valid
plugin module
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.baseuser
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.batch
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ca

2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.caacl
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.cert
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.certprofile
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.config
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.delegation
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dns
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.dnsserver
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dogtag
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.domainlevel
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.group
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbac
2016-12-05T19:13:45Z DEBUG ipaserver.plugins.hbac is not a valid plugin
module
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.hbacrule
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbacsvc
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.hbacsvcgroup
2016-12-05T19:13:45Z DEBUG importing plugin module
ipaserver.plugins.hbactest
2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.host
2016-12-05T19:13:45Z DEBUG 

Re: [Freeipa-users] Directory Manager Password Change

[Florence Blanc-Renaud]

On 12/05/2016 01:05 PM, Callum Guy wrote:

Hi All,

I have been testing FreeIPA and now plan to migrate to production use -
thanks for creating such a great application!

During the test phase we have been using simple passwords for the admin
and directory manager users however we need these changed before moving
into production. I believe we can change the admin password using the
web interface however as I understand it amending the directory manager
password is not so straightforward.

I have found this
link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password 
however
I am unsure if this is the correct procedure for our installation -
certainly i am having no luck so far.

We have the following setup:

FreeIPA 4.2.0 - single master server (no replicas), multiple clients
CentOS 7.2

I have tried the following steps in order:

http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html
followed by
https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

After completing that I am no longer able to authenticate user logins.
The below covers my current situation:

This works:
ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b ""
"objectclass=*"

This does not work:
ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b ""
"objectclass=*"

This works:
ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca"
-W -b "" -s base
OLDPASSWORD

This does not work:
ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca"
-W -b "" -s base
NEWPASSWORD


Hi,

your commands show that the Directory Manager password was properly 
modified, but not admin's password. Did you run the step 3 Updating PKI 
admin password of the procedure [1]?
ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W 
-T /root/dm_password "uid=admin,ou=people,o=ipaca"


Flo.

[1] 
https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password



So i'm i a mixed up state! Is anyone able to offer advise on resolving
this issue?

Thank you,

Callum





*^0333 332   |  www.x-on.co.uk   |  _
**_^
 
  *
X-on is a trading name of Storacall Technology Ltd a limited company
registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel
Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the
addressee(s) only. If you are not the intended recipient, please notify
X-on immediately on +44(0)333 332  and delete the
message from your computer. If you are not a named addressee you must
not use, disclose, disseminate, distribute, copy, print or reply to this
email. Views or opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its
associated companies. Although X-on routinely screens for viruses,
addressees should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the absence
of viruses in this email or any attachments.





--
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] updating certificates

[Florence Blanc-Renaud]

On 12/24/2016 01:58 AM, Josh wrote:

Hi Rob,

I'd like to really clarify renew certificate process. I can successfully
update certificates in /etc/dirsrv/slapd-domain and /etc/httpd/alias but
any new ipa client gets expired certificate still present someplace in
LDAP. I was trying to use ipa-server-certinstall, described in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html
but document does not cover the case where intermediate certificate is
required.

Hi Josh,

if the HTTP and LDAP certificates were signed by an intermediate CA, 
then you need to install both the root CA and the intermediate CA with 
ipa-cacert-manage install:


1/ install the root CA (if not already done)
ipa-cacert-manage install rootcert.pem
ipa-certupdate (on all the servers and clients)

2/ install the intermediate CA (if not already done)
ipa-cacert-manage install intermediatecert.pem
ipa-certupdate (on all the servers and clients)

3/ install the HTTP and LDAP certificates
ipa-server-certinstall ...

HTH,
Flo



Josh.

On 07/11/2016 10:10 AM, Rob Crittenden wrote:

j...@use.startmail.com wrote:

On Tuesday, June 28, 2016 10:50 AM, Rob Crittenden
 wrote:

j...@use.startmail.com wrote:

Greetings,

About a year ago I installed my freeipa server with certificates from
startssl using command line options --dirsrv-cert-file
--http-cert-file
etc.
The certificate is about to expire, what is the proper way to
update it
in all places?


It depends on whether you kept the original CSR or not. If you kept the
original CSR and are just renewing the certificate(s) then when you get
the new one, use certutil to add the updated cert to the appropriate
NSS
database like:

# certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i
/path/to/new.crt



Rob,

Thank you, that worked just fine, except that I had to update an
intermediate certificate as well.

Two questions, please:

1. I noticed a strange discrepancy in behavior between
/etc/httpd/alias and /etc/dirsrv/slapd-domain.
In both places original intermediate certificate is listed with empty
",," trust attributes so I initially added new intermediate
certificate with empty attributes as well.
certutils -V showed valid certificate in /etc/httpd/alias and not
trusted in /etc/dirsrv/slapd-domain so I had to modify intermediate
certificate with -t "C,,"


Hmm, not sure. Did the CA chain change in between the issuance of the
two certs?

Adding a new certificate shouldn't affect the trust of any other certs
so I'm not sure what happened. It could be that those subordinate CAs
were loaded the first time incorrectly but weren't used so it wasn't
noticed, I'm not really sure.


2. Just out of curiosity I wanted to list private keys and is
prompted for a password:
# certutil -K -d /etc/httpd/alias/
certutil: Checking token "NSS Certificate DB" in slot "NSS User
Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":

Which one of the many provided by a user passwords is used by
ipa-server-install command during NSS database initialization?


In each NSS directory there is a pwdfile.txt which contains the PIN
for the internal token. You can add -f /etc/httpd/alias/pwdfile.txt to
your command to list the private keys.

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] Replica issue / Certificate Authority

[Florence Blanc-Renaud]

On 01/04/2017 12:41 PM, Christophe TREFOIS wrote:

Hi Fraser,

We encountered the same issue. We exported the certificate from a "good"
replica, using certutil.
We then used certutil -A -n ipaCert -d /etc/httpd/alias/ -i
/opt/sysadmin/cacert.crt -a -t CT,C on the bad server and then restarted
ipa, and certmonger.

Now, the certificate is correct both using the certutil command and the
getcert list -n ipaCert command.

However, we see an "ca-error: Invalid cookie: ''  "  in the output of
getcert list -n ipaCert.


Hi Christophe,

is this error displayed on the renewal master? If not, you can run
$ getcert resubmit -i 
and the error should go away. On non-renewal master, resubmit downloads 
the certificate from LDAP (it does not ask for renewal), meaning that 
this operation cannot be harmful.


To know which server is the renewal master:
$ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password 
-b "cn=masters,cn=ipa,cn=etc,$BASEDN" 
'(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn

dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,$BASEDN

=> the renewal master is server.example.com

HTH,
Flo


Did we import the certificate correctly and should we worry about this
ca-error?
It seems replication is going fine, and also ipa-server-upgrade completes
successfully when run manually (whereas it failed previously from the same
error as in this thread)

Thanks for any pointers on how to clean the issue up properly,
Kind regards,

Christophe


-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Fraser Tweedale
Sent: lundi 19 décembre 2016 00:11
To: Christopher Young 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Replica issue / Certificate Authority

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 

Re: [Freeipa-users] section 2.3.6. Installing Without a CA - then how to update expired certificates in LDAP?

[Florence Blanc-Renaud]

On 12/24/2016 05:54 AM, Josh wrote:

I discussed this problem once before and got partial answers but I would
like to finally resolve it.

Scenario:

1. Install IPA without a CA, according to section 2.3.6 as of now in
latest RHEL7 Linux Domain Identity, Authentication and Policy Guide.
2. Install a client and note certificates it receives from IPA LDAP.
3. Near expiration term obtain a new set of certificates (server and
intermediate), note that intermediate certificate common name has changed.
4. run "ipa-server-certinstall -d -w key cert" to update all
certificates. command asks for directory manager password, I suppose it
should update its contents but
5. Install another client and observe that it receives original
certificates and no ipa command works.
6. ipa-certupdate, when run, pulls original set from LDAP as if nothing
was updated.

Workaround is to manually install new intermediate certificate on all
systems /etc/ipa/nssdb by
certutil -d /etc/ipa/nssdb/ -A -n "StartCom Class 1 DV Server CA -
StartCom Ltd." -t C,, -i /tmp/1_Intermediate.crt

In LDAP under cn=certificates,cn=ipa,cn=etc,dc=example,dc=org I still
see previous version of intermediate certificate with a different common
name:
StartCom Class 1 Primary Intermediate Server CA,OU=Secure Digital
Certificate Signing,O=StartCom Ltd.,C=IL

Please help me replace it by any means.

Best Regards,
Josh.


Hi Josh,

As you write that "intermediate certificate common name has changed", I 
assume that the intermediate CA providing the new server certificates is 
different. In this case, the command ipa-cacert-manage install must be 
run to install the new intermediate CA *before* ipa-server-certinstall 
is run to install the new server certificates.


Please refer to Installing a CA Certificate Manually [1] or Using 3rd 
part certificates for HTTP/LDAP [2]. Do not forget to run ipa-certupdate 
on all the IPA servers/clients in order to install the new intermediate 
CA cert.


HTH,
Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/manual-cert-install.html

[2] http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

--
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] Asking for help with crashed freeIPA istance

[Florence Blanc-Renaud]

On 01/04/2017 07:24 PM, Daniel Schimpfoessl wrote:

From the logs:
/var/log/dirsrv/slapd-DOMAIN-COM/errors
... a few warnings about cache size, NSACLPLugin and schema-compat-plugin
[04/Jan/2017:12:14:21.392642021 -0600] slapd started.  Listening on All
Interfaces port 389 for LDAP requests

/var/log/dirsrv/slapd-DOMAIN-COM/access
... lots of entries, not sure what to look for some lines contain RESULT
with err!=0
[04/Jan/2017:12:18:01.753400307 -0600] conn=5 op=243 RESULT err=32
tag=101 nentries=0 etime=0
[04/Jan/2017:12:18:01.786928085 -0600] conn=44 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress


Hi Daniel,

are there any RESULT err=48 that could correspond to the error seen on 
pki logs?


Flo


/var/log/dirsrv/slapd-DOMAIN-COM/errors
[04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down - signaling
operation threads - op stack size 5 max work q size 2 max work q stack
size 2
[04/Jan/2017:12:19:25.572566622 -0600] slapd shutting down - closing
down internal subsystems and plugins


2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl <dan...@schimpfoessl.com
<mailto:dan...@schimpfoessl.com>>:

Do you have a list of all log files involved in IPA?
Would be good to consolidate them into ELK for analysis.

2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>>:

On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:

Thanks for your reply.

This was the initial error I asked for help a while ago and
did not get
resolved. Further digging showed the recent errors.
The service was running (using ipactl start --force) and
only after a
restart I am getting a stack trace for two primary messages:

Could not connect to LDAP server host wwgwho01.webwim.com
<http://wwgwho01.webwim.com>
<http://wwgwho01.webwim.com> port 636 Error
netscape.ldap.LDAPException:
Authentication failed (48)
...

Internal Database Error encountered: Could not connect to
LDAP server
host wwgwho01.webwim.com <http://wwgwho01.webwim.com>
<http://wwgwho01.webwim.com> port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
...

and finally:
[02/Jan/2017:12:20:34][localhost-startStop-1]:
CMSEngine.shutdown()


    2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud
<f...@redhat.com <mailto:f...@redhat.com>
<mailto:f...@redhat.com <mailto:f...@redhat.com>>>:

systemctl start pki-tomcatd@pki-tomcat.service



Hi Daniel,

the next step would be to understand the root cause of this
"Authentication failed (48)" error. Note the exact time of this
log and look for a corresponding log in the LDAP server logs
(/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing
BIND with err=48. This may help diagnose the issue (if we can
see which certificate is used for the bind or if there is a
specific error message).

For the record, a successful bind over SSL would produce this
type of log where we can see the certificate subject and the
user mapped to this certificate:
[...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
10.34.58.150
[...] conn=47 TLS1.2 128-bit AES; client CN=CA
Subsystem,O=DOMAIN.COM <http://DOMAIN.COM>; issuer
CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
[...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
[...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
[...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
dn="uid=pkidbuser,ou=people,o=ipaca"

Flo





--
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

[Florence Blanc-Renaud]

On 01/09/2017 01:27 PM, Ben .T.George wrote:

Hi LIst,

is there anyone faces/fixed this issue?

Regards,
BEn


Hi Ben,

the directory server fails to restart on the replica. Are there any 
specific error message in /var/log/dirsrv/slapd-$DOMAIN/errors and 
access log files? If you are hitting ticket 6575 [1], there should be an 
error about a missing Server-Cert certificate (similar to: "Can't find 
certificate Server-Cert"), and no Server-Cert in /etc/dirsrv/slap-$DOMAIN.


Otherwise we need to figure out what causes the dirsrv startup error.

Flo

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


On Sun, Jan 8, 2017 at 7:03 AM, Ben .T.George > wrote:

HI List,

how can i solve this? is this a bug ,normal behavior or any missing
configuration from my end,

Till now i didn't get ant clue on this.

Regards
Ben

On Thu, Jan 5, 2017 at 1:21 PM, Fraser Tweedale > wrote:

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
> 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
>
   

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Florence Blanc-Renaud]

On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:

Thanks for your reply.

This was the initial error I asked for help a while ago and did not get
resolved. Further digging showed the recent errors.
The service was running (using ipactl start --force) and only after a
restart I am getting a stack trace for two primary messages:

Could not connect to LDAP server host wwgwho01.webwim.com
<http://wwgwho01.webwim.com> port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
...

Internal Database Error encountered: Could not connect to LDAP server
host wwgwho01.webwim.com <http://wwgwho01.webwim.com> port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
...

and finally:
[02/Jan/2017:12:20:34][localhost-startStop-1]: CMSEngine.shutdown()


2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>>:

systemctl start pki-tomcatd@pki-tomcat.service




Hi Daniel,

the next step would be to understand the root cause of this 
"Authentication failed (48)" error. Note the exact time of this log and 
look for a corresponding log in the LDAP server logs 
(/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing BIND with 
err=48. This may help diagnose the issue (if we can see which 
certificate is used for the bind or if there is a specific error message).


For the record, a successful bind over SSL would produce this type of 
log where we can see the certificate subject and the user mapped to this 
certificate:

[...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to 10.34.58.150
[...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; 
issuer CN=Certificate Authority,O=DOMAIN.COM

[...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
[...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
[...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 
dn="uid=pkidbuser,ou=people,o=ipaca"


Flo

--
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] pki-tomcatd fails to start

[Florence Blanc-Renaud]

On 01/06/2017 04:47 PM, Jeff Goddard wrote:

Sorry for the typo. here is the correct output:
ldapsearch -h id-management-1.internal.emerlyn.com

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:




When I look at the certificates I get errors regarding a host service in
the keytab. Here is the output:

[root@id-management-1 ca]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20150116161829':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client
using default keytab: Keytab contains no suitable keys for
host/id-management-1.internal.emerlyn@internal.emerlyn.com
.
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-INTERNAL-EMERLYN-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-INTERNAL-EMERLYN-COM/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-INTERNAL-EMERLYN-COM',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM

subject: CN=id-management-1.internal.emerlyn.com
,O=INTERNAL.EMERLYN.COM

expires: 2017-01-16 16:18:29 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
INTERNAL-EMERLYN-COM
track: yes
auto-renew: yes
Request ID '20150116162120':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client
using default keytab: Keytab contains no suitable keys for
host/id-management-1.internal.emerlyn@internal.emerlyn.com
.
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=INTERNAL.EMERLYN.COM

subject: CN=id-management-1.internal.emerlyn.com
,O=INTERNAL.EMERLYN.COM

expires: 2017-01-16 16:21:20 UTC
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
Request ID '20151217174142':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM

subject: CN=CA Audit,O=INTERNAL.EMERLYN.COM

expires: 2017-01-05 16:18:01 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20151217174143':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS
Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS
Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM

subject: CN=OCSP Subsystem,O=INTERNAL.EMERLYN.COM

expires: 2017-01-05 16:17:58 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20151217174144':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage:

Re: [Freeipa-users] pki-tomcatd fails to start

[Florence Blanc-Renaud]

or auto-shutdown support:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: done init id=debug
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initialized debug
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initSubsystem
id=log
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: ready to init
id=log
[06/Jan/2017:11:13:55][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[06/Jan/2017:11:13:55][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[06/Jan/2017:11:13:55][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: about to look
for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: done init id=log
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initialized log
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initSubsystem
id=jss
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: ready to init
id=jss
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: about to look
for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: done init id=jss
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initialized jss
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: initSubsystem
id=dbs
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine: ready to init
id=dbs
[06/Jan/2017:11:13:55][localhost-startStop-1]: DBSubsystem: init()
mEnableSerialMgmt=true
[06/Jan/2017:11:13:55][localhost-startStop-1]: Creating
LdapBoundConnFactor(DBSubsystem)
[06/Jan/2017:11:13:55][localhost-startStop-1]: LdapBoundConnFactory: init
[06/Jan/2017:11:13:55][localhost-startStop-1]:
LdapBoundConnFactory:doCloning true
[06/Jan/2017:11:13:55][localhost-startStop-1]: LdapAuthInfo: init()
[06/Jan/2017:11:13:55][localhost-startStop-1]: LdapAuthInfo: init begins
[06/Jan/2017:11:13:55][localhost-startStop-1]: LdapAuthInfo: init ends
[06/Jan/2017:11:13:55][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[06/Jan/2017:11:13:55][localhost-startStop-1]: makeConnection:
errorIfDown true
[06/Jan/2017:11:13:55][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert nickname to:
subsystemCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]: LdapJssSSLSocket: set
client auth cert nickname subsystemCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[06/Jan/2017:11:13:55][localhost-startStop-1]: Candidate cert:
caSigningCert cert-pki-ca
[06/Jan/2017:11:13:55][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: null
[06/Jan/2017:11:13:55][localhost-startStop-1]: SSL handshake happened
[06/Jan/2017:11:13:55][localhost-startStop-1]: CMSEngine.shutdown()

Is there something esle I should be looking at?

Jeff



On Fri, Jan 6, 2017 at 11:23 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 01/06/2017 04:47 PM, Jeff Goddard wrote:

Sorry for the typo. here is the correct output:
ldapsearch -h id-management-1.internal.emerlyn.com
<http://id-management-1.internal.emerlyn.com>
<http://id-management-1.internal.emerlyn.com
<http://id-management-1.internal.emerlyn.com>>
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:




When I look at the certificates I get errors regarding a host
service in
the keytab. Here is the output:

[root@id-management-1 ca]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20150116161829':
status: MONITORING
ca-error: Error setting up ccache for "host" service on
client
using default keytab: Keytab contains no suitable keys for
host/id-management-1.internal.emerlyn@internal.emer

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Florence Blanc-Renaud]

On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote:

Good day and happy holidays,

I have been running a freeIPA instance for a few years and been very
happy. Recently the certificate expired and I updated it using the
documented methods. At first all seemed fine. Added a Nagios monitor for
the certificate expiration and restarted the server (single server). I
have weekly snapshots, daily backups (using Amanda on the entire disk).

One day the services relying on IPA failed to authenticate. Looking at
the server the ipa service had stopped. Restarting the service fails.
Restoring a few weeks old snapshot does not start either. Resetting the
date to a few month back does not work either as httpd fails to start .

I am at a loss.

Here a few details:
# ipa --version
VERSION: 4.4.0, API_VERSION: 2.213


# /usr/sbin/ipactl start
...
out -> Failed to start pki-tomcatd Service
/var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server
host ipa.myorg.com  port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to
error: Retrieving CA status failed with status 500

Any help would be appreciated as all connected services are now down.

Thanks,

Daniel





Hi Daniel,

more information would be required to understand what is going on. First 
of all, which certificate did you renew? Can you check with

$ getcert list
if other certificates also expired?

PKI fails to start and the error seems linked to the SSL connection with 
the LDAP server. You may want to check if the LDAP server is listening 
on the LDAPs port:

- start the stack with
$ ipactl start --force
- check the LDAPs port with
$ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w 
password -b "" -s base


The communication between PKI and the LDAP server is authenticated with 
the certificate 'subsystemCert cert-pki-ca' located in 
/etc/pki/pki-tomcat/alias, so you may also want to check if it is still 
valid.
The directory server access logs (in 
/var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the connection 
with logs similar to:


[...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to 10.34.58.150
[...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; 
issuer CN=Certificate Authority,O=DOMAIN.COM

[...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
[...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
[...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 
dn="uid=pkidbuser,ou=people,o=ipaca"




HTH,
Flo

--
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] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/16/2016 03:54 PM, Florence Blanc-Renaud wrote:

On 12/15/2016 08:01 PM, beeth beeth wrote:

Hi Flo,

That's a good point! I checked the dirsrv certificate and confirmed
valid(good until later next year).
Since I had no problem to enroll another new IPA client(RHEL7 box
instead of RHEL6) to such replica server, I thought it might not be a
server end issue. However, when I tried to restart the DIRSRV service on
the replica server, I found these messages in the log
file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors:

[15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10
<http://1.3.5.10> B2016.257.1817 starting up
[15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match
[15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 5488640 B; We recommend to increase
the entry cache size nsslapd-cachememsize.
[15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled
schema-compat-plugin tree scan in about 5 seconds after the server
startup!
[15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target
cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target
ou=sudoers,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target
cn=automember rebuild membership,cn=tasks,cn=config does not exist
[15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition
cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS
Templates found, which should be added before the CoS Definition.
[15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipaprd2.example@ipa.example.com
<mailto:ipaprd2.example@ipa.example.com>] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[15/Dec/2016:13:38:16.479213976 -0500] slapd started.  Listening on All
Interfaces port 389 for LDAP requests

Re: [Freeipa-users] Ipa cert automatic renew Failing.

[Florence Blanc-Renaud]

On 12/21/2016 07:52 PM, Lucas Diedrich wrote:

Hello guys,

I'm having some trouble with, whats is happening with my server is that
i'm hiting an old BUG
(https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti
over irc he oriented me to send this to the email list.

The problem is, i got on CA Master, so because of this problem the CA
Master certificates couldn't be renewd, so now i promoted another master
to be the CA. And the problem still persist.

This is the certs from my new CA
(https://paste.fedoraproject.org/510617/14823448/),
this is the certs from my old CA
(https://paste.fedoraproject.org/510618/44871148/)
This is the log then i restart pki-tomcat( "CA port 636 Error
netscape.ldap.LDAPException: Authentication failed (49)")
This is the log from dirsrv when i restart pki-tomcat
(https://paste.fedoraproject.org/510614/23446801/)

Basically my CA is not working anymore...

Anyway, i tried lots of thing but couldn't fix this, anyone has some idea?




Hi,

Pki-tomcat is using the LDAP server as a data store, meaning that it 
needs to authenticate to LDAP. In order to do that, pki-tomcat is using 
the certificate 'subsystemCert cert-pki-ca' stored in 
/etc/pki/pki-tomcat/alias. For the authentication to succeed, the 
certificate must be stored in a user entry 
(uid=pkidbuser,ou=people,o=ipaca).


Can you check the content of this entry, especially the usercertificate 
attribute? It should match the certificate used by pki-tomcat:


$ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

$ kinit admin
$ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b 
uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate

dn: uid=pkidbuser,ou=people,o=ipaca
usercertificate:: 

The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this 
certificate in the directive ca.subsystem.cert.



A possible cause for the entries not being updated is the bug 1366915 
[1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux 
on Fedora 24.


Flo

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188

--
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] backing up and starting over...

[Florence Blanc-Renaud]

On 12/21/2016 10:26 PM, Robert Story wrote:

I'm running a small instance of freeipa on CentOS 7 in our lab, for about 20
machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things
have gotten flaky. e.g. clicking on a user get the spinning 'Working'
dialog and can take 3-5 minutes to load the page. But often it will die
with 'internal error'.

Is there a way to back up data so that I can re-install 4.4 and restore the
data? Specifically users+uids/groups+gids, HBAC and sudo rules?


Robert




Hi,

you can find more information about backup and restore procedure in this 
guide [1]. But, as stated in the documentation, the safest method would 
rather be to install a replica [2].


HTH,
Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/backup-restore.html
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html


--
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 cert automatic renew Failing.

[Florence Blanc-Renaud]

On 12/22/2016 01:15 PM, Lucas Diedrich wrote:

Florence, for some creepy reason the cert from pkidbuser is different
from subsystem certs, and this pkidbuser is outdated now, but i can't
manage one way to re-issue it. I had to change the CA server because of
that, and the Selinux in the old CA Server was disabled, on the new one
is in Permissive mode but doesn't a warning in /var/log/audit/audit.log.

This is the pkidbuser cert: https://paste.fedoraproject.org/511023/24084431/
This is the subsystem cert: https://paste.fedoraproject.org/511025/14824085/
The ca.subsystem.cert matches the pkidbuser cert.

lucasdiedrich.


Hi,

you can try to manually call the post-save command that certmonger 
should have issued after putting the certificate in 
/etc/pki/pki-tomcat/alias:

on the renewal master:
$ sudo /usr/libexec/ipa/certmonger/stop_pkicad
$ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"

Then check the journal log that should display the following if 
everything goes well:

$ sudo journalctl --since today | grep renew_ca_cert
[...] renew_ca_cert[6478]: Updating entry 
uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca

[...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca
[...] renew_ca_cert[6478]: Starting pki_tomcatd
[...] renew_ca_cert[6478]: Started pki_tomcatd

If the operation does not succeed, you will have to check the LDAP 
server logs in /etc/dirsrv/slapd-DOMAIN/access.


HTH,
Flo.


Em qui, 22 de dez de 2016 às 06:54, Florence Blanc-Renaud
<f...@redhat.com <mailto:f...@redhat.com>> escreveu:

On 12/21/2016 07:52 PM, Lucas Diedrich wrote:
> Hello guys,
>
> I'm having some trouble with, whats is happening with my server is
that
> i'm hiting an old BUG
> (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to
mbasti
> over irc he oriented me to send this to the email list.
>
> The problem is, i got on CA Master, so because of this problem the CA
> Master certificates couldn't be renewd, so now i promoted another
master
> to be the CA. And the problem still persist.
>
> This is the certs from my new CA
> (https://paste.fedoraproject.org/510617/14823448/),
> this is the certs from my old CA
> (https://paste.fedoraproject.org/510618/44871148/)
> This is the log then i restart pki-tomcat( "CA port 636 Error
> netscape.ldap.LDAPException: Authentication failed (49)")
> This is the log from dirsrv when i restart pki-tomcat
> (https://paste.fedoraproject.org/510614/23446801/)
>
> Basically my CA is not working anymore...
>
> Anyway, i tried lots of thing but couldn't fix this, anyone has
some idea?
>
>
>
Hi,

Pki-tomcat is using the LDAP server as a data store, meaning that it
needs to authenticate to LDAP. In order to do that, pki-tomcat is using
the certificate 'subsystemCert cert-pki-ca' stored in
/etc/pki/pki-tomcat/alias. For the authentication to succeed, the
certificate must be stored in a user entry
(uid=pkidbuser,ou=people,o=ipaca).

Can you check the content of this entry, especially the usercertificate
attribute? It should match the certificate used by pki-tomcat:

$ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -a
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

$ kinit admin
$ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
dn: uid=pkidbuser,ou=people,o=ipaca
usercertificate:: 

The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this
certificate in the directive ca.subsystem.cert.


A possible cause for the entries not being updated is the bug 1366915
[1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux
on Fedora 24.

Flo

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188





--
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-devel] Certificate expiration consequences

[Florence Blanc-Renaud]

On 12/22/2016 12:22 PM, Pablo Hinojosa wrote:

Hi all,

I have realized my Freeipa webui ssl certificate is near to expire. It
is supposed to auto-renew but it seems I am affected by this bug/defect
 (maybe due to a
missconfigured installation). Here
 you can check current
status with getcert list.

My main priority is to know if LDAP login will work when certificated is
expired. Will I have problems with it? Will login blocked? or it will
work as expected.

Thanks for your support

Cheers,

--

Pablo Hinojosa
System administrator
Kanteron Systems (kanteron.com )




Hi Pablo,

(moving this discussion to freeipa-users).

you probably have other certificates already expired in your deployment 
(auditSigningCert cert-pki-ca, ocspSigningCert cert-pki-ca, 
subsystemCert cert-pki-ca, Server-Cert cert-pki-ca in 
/etc/pki/pki-tomcat/alias and ipaCert in /etc/httpd/alias).


The best thing to do would be to fix this problem first, and the HTTPd 
and LDAP server certificates should be able to renew automatically.


The following document [1] may help you. The general idea is to find 
which certificate expired first, go back in time (by changing the date 
of your server) and manually renew the certificates.


If your LDAP and HTTP certificates are already expired, the 
documentation [2] explains how to start IPA stack and also lists the 
limitations when running with expired certificates.


HTH,
Flo.


[1] https://access.redhat.com/solutions/643753
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/expired-certs.html


--
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] AD-Trust Replica

[Florence Blanc-Renaud]

On 03/22/2017 09:33 AM, Wimmer Ronald (BCC.B.SO) wrote:

Hi,



do I have to setup the AD-trust on the Replica as well? Or is it just
the master server where it has to be set up?



Regards,

Ronald






Hi,

the following chapter may help you understand the different roles for an 
IdM master wrt AD trust (normal IdM master, trust agent or trust 
controller):


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-controller-agent

Flo

--
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 creation problems

[Florence Blanc-Renaud]

On 04/13/2017 07:50 PM, Josh wrote:

Scenario:

RHEL7 IPA with DNS and without CA. Initial installation was done using
--http-cert-file, --dirsrv-cert-file with certificates from an issuer A.

For a number of reasons replica must be created with certificates from
an issuer B.

A bundle consisting of key, server certificate and a full certificate
chain provided by the issuer B is prepared as replica.crt

IPA Replica file created as

ipa-replica-prepare --dirsrv-cert-file=replica.crt
--http-cert-file=replica.crt --dirsrv-pin=key_pass --http-pin=key_pass
--ip-address=n.n.n.n --password=manager_pass replica_host_name

no errors/warnings during above process.

Resulting file transferred to a new clean system and launched as

# ipa-replica-install --setup-dns --auto-forwarders --mkhomedir
/var/lib/ipa/replica-replica_host_name.gpg
Directory Manager (existing master) password:

Checking DNS forwarders, please wait ...
Run connection check to master
admin@REALM password:
Connection check OK
Adding [n.n.n.n replica_host_name] to your /etc/hosts file
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/42]: creating directory server user
  [2/42]: creating directory server instance
  [3/42]: updating configuration in dse.ldif
  [4/42]: restarting directory server
  [5/42]: adding default schema
  [6/42]: enabling memberof plugin
  [7/42]: enabling winsync plugin
  [8/42]: configuring replication version plugin
  [9/42]: enabling IPA enrollment plugin
  [10/42]: enabling ldapi
  [11/42]: configuring uniqueness plugin
  [12/42]: configuring uuid plugin
  [13/42]: configuring modrdn plugin
  [14/42]: configuring DNS plugin
  [15/42]: enabling entryUSN plugin
  [16/42]: configuring lockout plugin
  [17/42]: configuring topology plugin
  [18/42]: creating indices
  [19/42]: enabling referential integrity plugin
  [20/42]: configuring ssl for ds instance
  [21/42]: configuring certmap.conf
  [22/42]: configure autobind for root
  [23/42]: configure new location for managed entries
  [24/42]: configure dirsrv ccache
  [25/42]: enabling SASL mapping fallback
  [26/42]: restarting directory server
  [27/42]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 15 seconds elapsed
[master_host_name] reports: Update failed! Status: [-11  - LDAP error:
Connect error]

  [error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORFailed to
start replication
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log
for more information

Log file does not list any obvious errors other then full call stack
which tell  me nothing, I can post it here if helps.
Both machines run no firewall and are on the same subnet.

Additional problems noticed during cleanup attempt:

# /usr/sbin/ipa-server-install --uninstall

This is a NON REVERSIBLE operation and will delete all data and
configuration!

Are you sure you want to continue with the uninstall procedure? [no]: yes

Replication agreements with the following IPA masters found:
master_host_name. Removing any replication agreements before
uninstalling the server is strongly recommended. You can remove replication
agreements by running the following command on any other IPA master:
$ ipa-replica-manage del replica_host_name

Are you sure you want to continue with the uninstall procedure? [no]:

Aborting uninstall operation.



Going to master and running

$ ipa-replica-manage del replica_host_name

fails with

Connection to 'replica_host_name' failed: cannot connect to
'ldaps://replica_host_name:636': TLS error -8172:Peer's certificate
issuer has been marked as not trusted by the user.
Unable to delete replica 'replica_host_name'

I attempted to provide --cacert=full_path_to_issuer_B_bundle option but
nothing changed. As a matter of fact providing invalid file name to
--cacert does not raise any error. Strace output confirm that file
listed in --cacert is not Only appending the bundle to /etc/ipa/ca.crt
resolved TLS errors.


Please advise how I can find root cause of LDAP error: Connect error.
I have a suspicion that master LDAP can't connect to replica LDAP for
above mentioned TLS reason.

Josh.


Hi Josh,

I did not try this type of setup myself, but I think the issue comes 
from missing root certificates. I would try to run

$ ipa-cacert-manage --install 
$ ipa-certupdate
on the master. This command will install issuer B certificate as a 
trusted CA on the master, thus allowing communications with services (eg 
LDAP on replica) using certificates delivered by issuer B.


You may find more information in 

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

[Florence Blanc-Renaud]

Hi,

Which 'FreeIPA certificate' are you referring to? If you installed 
FreeIPA CA-less, then the root certificate was used to sign LDAP and 
HTTPd certificates and you can follow this page [1] to use a different 
CA and replace LDAP and HTTPd certs.


If you installed IPA with an integrated CA, then the root certificate 
was used to sign IPA CA certificate, and the other certificates used by 
FreeIPA were signed by IPA CA. In this case you would have to replace 
IPA CA with [2] and then renew LDAP and HTTPd certificates [3].


Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html


[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext


[3] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replace-HTTP-LDAP-cert.html


On 03/10/2017 01:16 PM, 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



--
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] Make Gpg replica fail , where cert store I should update new ?

[Florence Blanc-Renaud]

Hi,

In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as 
Certificate Authority, and this file may be outdated. Running 
ipa-certupdate may fix your issue. See [1]


If it doesn't, you can start by identifying which certificate expired with
$ sudo getcert list | egrep -e 'expires|Request ID|subject'

HTH,
Flo

[1] https://pagure.io/freeipa/issue/6375

On 03/07/2017 04:14 AM, barry...@gmail.com wrote:

gpg

Creating SSL certificate for the Directory Server
ipa : ERRORcert validation failed for "CN=central.ABC.com
,O=ABC.COM "
((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)
preparation of replica failed: cannot connect to
'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient':
(SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
cannot connect to
'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient':
(SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
  File "/usr/sbin/ipa-replica-prepare", line 490, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 361, in main
export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert",
replica_fqdn, subject_base)

  File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb
raise e





--
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 deleting IPA host: SSL peer cannot verify your certificate

[Florence Blanc-Renaud]

On 04/05/2017 01:17 AM, Chris Herdt wrote:

Although I had previously been using a self-signed certificate, I
recently started using a cert signed by InCommon CA on my FreeIPA
master (still on IPA 3.0.0 at this time).

I added the certificate and intermediate certificates to
/etc/ssl/certs and the certificate database in
/etc/dirsrc/slapd-EXAMPLE-COM. /etc/httpd/conf.d/nss.conf is pointing
to the new certificate for NSSNickname.

I can log into the web UI, but when I attempt to delete a host I get
the following error:

Operations Error
Some entries were not deleted
Show details

Under "Show details":
cannot connect to
'https://freeipa.example.com:443/ca/agent/ca/displayBySerial':
(SSL_ERROR_BAD_CERT_ALERT) SSL peer cannot verify your certificate.

Likewise, if I attempt to delete a host using the CLI I get an error message:

# ipa host-del host-01.example.com
ipa: ERROR: cert validation failed for
"CN=freeipa.example.com,OU=Example Unit,O=Example Org,L=Example
City,ST=MN,C=US" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://freeipa.example.com/ipa/xml

If I enable the verbose flag -vv, I see that it is making an HTTP POST
request to https://freeipa.example.com/ipa/xml.

It looks like Firefox on my local client trusts the certificate, but
that the server itself does not trust its own certificate when
connecting to itself. Can anyone advise on how I can address this
issue?



Hi,

the certificate and intermediate certificates need to be added to all 
the NSS databases used by FreeIPA. You can find instructions in the page 
"Using 3rd part certificates for HTTP/LDAP > Procedure in IPA < 4.1" [1].


HTH,
Flo

[1] 
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1


--
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 didn't automatically transfer to replica(s)

[Florence Blanc-Renaud]

On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Master IPA Server:
- - I install 1 (one) server as master (self-signed) and add/modify
using external CA.
- - I am using ipa-cacert-manage install then ipa-certupdate on master


Hi,

I think I got you wrong...
Do you mean that you installed IPA with an integrated IdM CA which was 
self-signed, then your intent was to move to integrated IdM CA 
externally signed? In this case, the right command would be 
ipa-cacert-manage renew --external-ca, and the procedure is described in 
"Changing the certificate chain" [1].


The command ipa-cacert-manage install does not replace the integrated 
IdM CA but adds the certificate as a known CA.


Hope this clarifies,
Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-cert-chaining.html



Replica IPA Server:
- - I install 1 (one) server as client and promoted to ipa-replica:
  - I run `ipa-client-install` and autodiscovery
  - Then `ipa-replica-install --principal admin --admin-password
`

I've hit ipa-certupdate -v to verbose the logs (attached at first
email). Then replica server aren't using external CA(s) like master did.

So, I did the same like master, using `ipa-cacert-manage` on replica,
and it's work fine. If it's normal, then thanks for clarifying this.

On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote:

Hi,

As your email refers to self-signed and signed CA certificate, can
you please clarify the exact steps that you followed? It looks
like - you first installed FreeIPA with a self-signed CA - you
added an external CA (did you use ipa-cacert-manage install on 1
server then ipa-certupdate on all replicas?) - you replaced the
httpd/LDAP certificates with a cert signed from the external CA
(you probably ran ipa-server-certinstall on one server).

In this case it is normal that the httpd/LDAP certificates on the
replica were not updated as they are different (each IPA server has
his own httpd/LDAP cert which contains the hostname in its
subject). You can check this by performing on each server:
ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert |
grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM"
^

If the goal is to replace the httpd/LDAP certificates on the
replica, the command ipa-server-certinstall must also be run on the
replica with the appropriate certificate.

HTH, Flo.

On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello!

Just update, manually add external CA(s) and signed certificated
was successful, but why it's didn't automatically transferred to
replica(s) from master.

On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:

Hello!

I've successfully create replica, everything works fine but
why my signed CA certificate didn't automatically transfer to
another replica(s)? Is it normal?

Trying to add manually, but the certificate in replica(s)
still using self-signed. Here's the output from
`ipa-certupdate -v`
https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdI

GYh





yR




LivL9gydE=


Interesting line was :

ipa: DEBUG: stderr= ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n
IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa:
DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found

ipa: DEBUG: Starting external process ipa: DEBUG:
args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA
cert -a ipa: DEBUG: Process finished, return code=255 ipa:
DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not
found

FYI: The replica server previously was a client and promoted
to be a replica by hitting this command:
`ipa-replica-install --principal admin --admin-password
admin_password`

Any hints?






-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY/w9DGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcBkZD/wM9ia9854l7bIy7dHxKxc7WhduFmbW3AwW0Ren+aLLER/lqMhO
KPNA+fB9ojeoZagmA7JhpM9jblJ4BUaJjLnyf1vhJmOgIX0MgSfmNCr/f/EtfC9R
wZLBImntbGm8yQnsA4f21sdmqnQg9CZN6cg6R8TQ+OuAXdm8jU9Pv3RCLFXzS0mW
oxQdOZ9yNOC9chmfGl6Bz2oGFoEMHCsn1AcEoRHyIUU6jrCNhTVgYcHPVEz0PW73
DEY0ZkwNi9hMcGv5+5F8InYEOdOkS9Lp0juW47xRheztD/PRhYYn1m/FtOxmFa3z
3XS36/w6omSdfH2WOjBRwJduB4REmwHb9oGto7vu6FvWhwUHf9zWVjmJ6DH8tbYU
XgHLmmaSIfwHWc0iYnSLcbHuOaR+l2nOSOLJNg5FfUoIJy5qO51kV3u+pGGELCdr
GexkcXrEHxqk/OO9ioLlTfYIpd9NI6hdLzAsjJEbHuEVZe1B/nrkUOVy/yWOry0N
8muLkJlslMpRwGV4KRFlhcfd49mv9oylKrAxtZ843vz6F1WOKI6vbuS+SJ+wpoer
P1njVQyExrlKi3ruPBIOkxQ6fab9OvredesCo13wLqhfXvezsWpL1RkiqBaMzrsk
NDX/jqEEsk7gbYuawNazcQZP/NGzQZ6nBnVAkXV7vA8D/EV4y1CbW9YfXA==
=07Ri
-END PGP SIGNATURE-



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freei

Re: [Freeipa-users] I think I lost my CA...

[Florence Blanc-Renaud]

On 04/26/2017 04:33 PM, Bret Wortman wrote:

So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

# ipa cert-find
:
--
Number of entries returned 385
--
# ipa cert-show 895
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
# ipa cert-show 1 (which does not exist)
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
# ipa cert-status 895
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
#

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.


Hi Bret,

the issue looks similar to https://pagure.io/freeipa/issue/6575 and 
https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note 
that IPv6 must be enabled on the machine but IPA does not require an 
IPv6 address to be configured (except for the loopback).


You can check the following:
- is PKI listening to port 8009 on IPv6 or IPv4 interface?
sudo netstat -tunpl | grep 8009
tcp6   0  0 127.0.0.1:8009  :::* LISTEN  10749/java

- /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009 to 
8443, and the "address" part is important:



In the above example, it will be using localhost which can resolve 
either to IPv4 or IPv6.


- /etc/hosts must define the loopback addresses with
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 
localhost6.localdomain6


HTH,
Flo.

Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:


Digging still deeper:

# ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA thinks
it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:


Using the firefox debugger, I get these errors when trying to pop up
the New Certificate dialog:

Empty string passed to getElementById(). (5)
jquery.js:4:1060
TypeError: u is undefined
app.js:1:362059
Empty string passed to getElementById(). (5)
jquery.js:4:1060
TypeError: t is undefined
app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:


Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any other server?


Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:


I recently had to upgrade all my Fedora IPA servers to C7. It went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate for
their web server. All was good until I went to the IPA UI and tried
to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

# ipa ca-find

1 CA matched

  Name: ipa
  Description IPA CA
  Authority ID: 3ce3346[...]
  Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
  Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM

Number of entries returned 1

# ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
O=DAMASCUSGRP.COM"
ipa: ERROR: Failed to authenticate to CA REST API
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@damascusgrp.com

Valid starting  Expires  Service principal
04/25/2017 18:48:26 04/26/2017 18:48:21
krbtgt/damascusgrp@damascusgrp.com
#


What's my best path of recovery?

--
*Bret Wortman*
The Damascus Group



















--
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 didn't automatically transfer to replica(s)

[Florence Blanc-Renaud]

On 04/28/2017 03:50 AM, Dewangga Bachrul Alam wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

On 04/26/2017 08:08 PM, Florence Blanc-Renaud wrote:

On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: Hello!

Master IPA Server: - I install 1 (one) server as master
(self-signed) and add/modify using external CA. - I am using
ipa-cacert-manage install then ipa-certupdate on master


Hi,



I think I got you wrong... Do you mean that you installed IPA
with an integrated IdM CA which was self-signed, then your intent
was to move to integrated IdM CA externally signed? In this case,
the right command would be ipa-cacert-manage renew --external-ca,
and the procedure is described in "Changing the certificate
chain" [1].


Ah thanks for your corrections and information, then what should I do?
Should I run ipa-cacert-manage renew --external-ca ?

Yes, this is the way to go, documented here [1]. This is a 2-step 
process: when the command is run, it will create a CSR that needs to be 
signed by an external CA. Then the command must be re-launched with the 
new certificate delivered by the CA.


Also do not forget to run ipa-certupdate on the master and all the 
replicas/clients.


Flo.

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext





The command ipa-cacert-manage install does not replace the
integrated IdM CA but adds the certificate as a known CA.



Hope this clarifies, Flo



[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu

x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-ce
rt-chaining.html






Replica IPA Server: - I install 1 (one) server as client and
promoted to ipa-replica: - I run `ipa-client-install` and
autodiscovery - Then `ipa-replica-install --principal admin
--admin-password `

I've hit ipa-certupdate -v to verbose the logs (attached at first
email). Then replica server aren't using external CA(s) like master
did.

So, I did the same like master, using `ipa-cacert-manage` on
replica, and it's work fine. If it's normal, then thanks for
clarifying this.

On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote:

Hi,

As your email refers to self-signed and signed CA
certificate, can you please clarify the exact steps that you
followed? It looks like - you first installed FreeIPA with a
self-signed CA - you added an external CA (did you use
ipa-cacert-manage install on 1 server then ipa-certupdate on
all replicas?) - you replaced the httpd/LDAP certificates
with a cert signed from the external CA (you probably ran
ipa-server-certinstall on one server).

In this case it is normal that the httpd/LDAP certificates on
the replica were not updated as they are different (each IPA
server has his own httpd/LDAP cert which contains the
hostname in its subject). You can check this by performing on
each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L
-n Server-Cert | grep Subject: Subject:
"CN=ipaserver.domain.com,O=DOMAIN.COM" ^

If the goal is to replace the httpd/LDAP certificates on the
replica, the command ipa-server-certinstall must also be run
on the replica with the appropriate certificate.

HTH, Flo.

On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello!

Just update, manually add external CA(s) and signed
certificated was successful, but why it's didn't
automatically transferred to replica(s) from master.

On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:

Hello!

I've successfully create replica, everything works fine
but why my signed CA certificate didn't automatically
transfer to another replica(s)? Is it normal?

Trying to add manually, but the certificate in
replica(s) still using self-signed. Here's the output
from `ipa-certupdate -v`
https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1U

NdI





GYh





yR




LivL9gydE=


Interesting line was :

ipa: DEBUG: stderr= ipa: DEBUG: Starting external
process ipa: DEBUG: args=/usr/bin/certutil -d
/etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: Process
finished, return code=255 ipa: DEBUG: stdout= ipa:
DEBUG: stderr=certutil: Could not find cert: IPA CA :
PR_FILE_NOT_FOUND_ERROR: File not found

ipa: DEBUG: Starting external process ipa: DEBUG:
args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External
CA cert -a ipa: DEBUG: Process finished, return
code=255 ipa: DEBUG: stdout= ipa: DEBUG:
stderr=certutil: Could not find cert: External CA cert
: PR_FILE_NOT_FOUND_ERROR: File not found

FYI: The replica server previously was a client and
promoted to be a replica by hitting this command:
`ipa-replica-install --principal admin
--admin-password admin_password`

Any hints?










-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJZAp/fGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcFhED/0VncBpnHq9jTIjQCel6wpqITpob3CeqtFMKFvx9gl6/7jKzkbO
1sNr8qcvB2Hne9mp41EDXhQw9ZLxNHTqt6JOAzdGFGO3

Re: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s)

[Florence Blanc-Renaud]

Hi,

As your email refers to self-signed and signed CA certificate, can you 
please clarify the exact steps that you followed? It looks like

- you first installed FreeIPA with a self-signed CA
- you added an external CA (did you use ipa-cacert-manage install on 1 
server then ipa-certupdate on all replicas?)
- you replaced the httpd/LDAP certificates with a cert signed from the 
external CA (you probably ran ipa-server-certinstall on one server).


In this case it is normal that the httpd/LDAP certificates on the 
replica were not updated as they are different (each IPA server has his 
own httpd/LDAP cert which contains the hostname in its subject). You can 
check this by performing on each server:
ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert | grep 
Subject:

Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM"
 ^

If the goal is to replace the httpd/LDAP certificates on the replica, 
the command ipa-server-certinstall must also be run on the replica with 
the appropriate certificate.


HTH,
Flo.

On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Just update, manually add external CA(s) and signed certificated was
successful, but why it's didn't automatically transferred to
replica(s) from master.

On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:

Hello!

I've successfully create replica, everything works fine but why my
signed CA certificate didn't automatically transfer to another
replica(s)? Is it normal?

Trying to add manually, but the certificate in replica(s) still
using self-signed. Here's the output from `ipa-certupdate -v`
https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYh

yR




LivL9gydE=


Interesting line was :

ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa:
DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a
ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA :
PR_FILE_NOT_FOUND_ERROR: File not found

ipa: DEBUG: Starting external process ipa: DEBUG:
args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a
ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert
: PR_FILE_NOT_FOUND_ERROR: File not found

FYI: The replica server previously was a client and promoted to be
a replica by hitting this command: `ipa-replica-install
--principal admin --admin-password admin_password`

Any hints?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY+xccGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcJAHEACO4nF7guN05MjmqYFDwDrjhvWgMN2sRn+Nxt/aA+xziIOJJGaA
Rr97TbODiTiefBkjVoiYM6dxr6VK5ViPZIbe0IAjafCRACAKggyCRtb2j8+vb7Jd
imJN/MC0zSMCdATSs2b95uT7QrUiVHwt/xmKzJ44ezIYON+YOtgndk0QXynXHqjm
H6HcQkh4ZcC8antiFdbC+H8z4Iv4Ypnhdr80RtqLqQ6esnZXnWdIg3X0aRb6w1fw
KEDHemhfKeu5hMxpi2AQdesO4j+XhvW6TfvKymScbWv1PoEuLAsgQGdoxVmhkjN8
LKixSghHlg8A61DXtA9J2uaPUUKjVMmoKH4CFD0RLQlQJ+f4KfApbNzHZTBnSL8D
64c5WjJdtAY5LUArakwZ/EJt5N5AJEFDIoSWM3if/jpDIVFEAaDzFKIQvyLKyMIn
yHxNIcWcSoP/YwzZXMttWx5dNRkermmWEcvPsqovoT9BRlI/e700o3xqQk7V0720
7TniU1uZaBpLkJOxHUoWssaWfVHcWEBnw0UeU7bl4nKnAo7hkQs3/iJXwQiLk4aw
338ZIniIrDSmUmmfqJuhQrFPNK+heCOno5O/99Sa1bs0lTQgRRjMq5Q7mIajEYYI
NedyVj0VQ8R42rbgomWJPJP/uU+kirN8CpEc+d/IWNQE2t+5hOX5nme5dw==
=anzk
-END PGP SIGNATURE-



--
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-install failes on setup-ca

[Florence Blanc-Renaud]

On 04/24/2017 09:37 AM, Bjarne Blichfeldt wrote:

We had problems with one idm replica complaining about different ldap
database versions and at the same time errors on starting pki-tomcat. I
decided to delete the ipa server and reinstall.

The ipa server delete went without problems, but the reinstall….



ipa-replica-install --setup-ca --setup-dns --forwarder 10.200.207.11
--forwarder  10.200.206.11 --principal admin --admin-password  “secret”



This fails on ca install, but without set-up ca the install was succesfull.

I tried both with the server enrolled as client and with the server not
enrolled – no difference.

The installation was successful in a different envirionment but same
software versions.





server is rhel 7.3, ipa: VERSION: 4.4.0, API_VERSION: 2.213



When ipa-replica-install fails  with –setup-ca  ipareplica-install.log
shows :

2017-04-23T19:44:45Z DEBUG Starting external process

2017-04-23T19:44:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X

2017-04-23T19:44:46Z DEBUG Process finished, return code=1

2017-04-23T19:44:46Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20170423214445.log

Loading deployment configuration from /tmp/tmpBLQe1X.



2017-04-23T19:44:46Z DEBUG stderr=Traceback (most recent call last):

  File "/usr/sbin/pkispawn", line 817, in 

main(sys.argv)

  File "/usr/sbin/pkispawn", line 501, in main

create_master_dictionary(parser)

  File "/usr/sbin/pkispawn", line 641, in create_master_dictionary

parser.compose_pki_master_dictionary()

  File
"/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py",
line 614, in compose_pki_master_dictionary

instance.load()

  File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line
595, in load

subsystem.load()

  File "/usr/lib/python2.7/site-packages/pki/server/__init__.py", line
129, in load

lines = open(self.cs_conf).read().splitlines()

IOError: [Errno 2] No such file or directory:
'/var/lib/pki/pki-tomcat/ca/conf/CS.cfg'



2017-04-23T19:44:46Z CRITICAL Failed to configure CA instance: Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpBLQe1X' returned non-zero exit status 1

2017-04-23T19:44:46Z CRITICAL See the installation logs and the
following files/directories for more information:

2017-04-23T19:44:46Z CRITICAL   /var/log/pki/pki-tomcat

2017-04-23T19:44:46Z DEBUG Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 449, in start_creation

run_step(full_msg, method)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 439, in run_step

method()

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
586, in __spawn_instance

DogtagInstance.spawn_instance(self, cfg_file)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 181, in spawn_instance

self.handle_setup_error(e)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 420, in handle_setup_error

raise RuntimeError("%s configuration failed." % self.subsystem)

RuntimeError: CA configuration failed.



2017-04-23T19:44:46Z DEBUG   [error] RuntimeError: CA configuration failed.

2017-04-23T19:44:46Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute

return_value = self.run()

  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line
318, in run

cfgr.run()

  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 310, in run

self.execute()

  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 332, in execute

for nothing in self._executor():





Nothing in /var/log/pki/pki-tomcat.



Further observations:

During changing the certificate to thirdparty ssl, I got the following
error in /var/log/httpd/error_log :

[Mon Apr 24 09:03:14.267871 2017] [:error] [pid 11004] Unable to verify
certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so
the server can start until the problem can be resolved.

p11-kit: couldn't open and map file:
/etc/pki/ca-trust/source/ipa.p11-kit: Permission denied



I changed the permission on /etc/pki/ca-trust/source/ipa.p11-kit from
600 to 644 and added “NSSEnforceValidCerts off” to
/etc/httpd/conf.d/nss.conf

After that ipa-certupdate succeeded.



Are there any way to install the ca without reinstalling the whole
ipa-server again?







Regards

Bjarne Blichfeldt.






Hi,

1/ you may find more information about the CA installation failure in 
/var/log/pki/pki-ca-spawn.$date.log


To enable debug logs, you can create the file /etc/ipa/server.conf:
$ cat /etc/ipa/server.conf
[global]
debug = True


2/ the error in httpd/error_log may indicate that your certificate 
expired, could you check if all the certificates are still valid?

$ sudo certutil -L -d /etc/httpd/alias/ -n Server-Cert | grep  Not
Not Before: Thu Apr 20 15:03:40 2017
 

Re: [Freeipa-users] How do you allow Active Directory Users to login to the webgui

[Florence Blanc-Renaud]

On 05/12/2017 04:09 PM, Tym Rehm wrote:

So I'm testing a new freeipa 4.x setup that has a one-way trust to
Active Directory. I have been able to define user groups to access the
AD groups and configure the groups to work with HBAC rules. So my AD
users are able to ssh into the client machines if HBAC allows them to.

The issue I'm having is that I would like to allow the AD users to login
to the webgui. I currently have the users in the defined in the ID views
(Default Trust View). I'm only setting the Home Directory at present,
should I add to the ID view?

Thanks

--
--
Do not meddle in the affairs of dragons cause you are crunchy and good
with ketchup.




Hi Tym,

this feature is available since FreeIPA 4.5.1 (see ticket 3242 [1]). You 
need to define a idoverrideuser for each AD user with:

$ ipa idoverrideuser-add 'Default Trust View' adu...@ad-domain.com

HTH,
Flo.

[1] https://pagure.io/freeipa/issue/3242

--
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 connect to LDAP server host - IO Error creating JSS SSL Socket:

[Florence Blanc-Renaud]

On 05/18/2017 03:49 PM, Michael Plemmons wrote:





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX
*
614.427.2411
mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
www.crosschx.com <http://www.crosschx.com/>

On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:

On 05/15/2017 08:33 PM, Michael Plemmons wrote:

I have done more searching in my logs and I see the following
errors.

This is in the localhost log file /var/lib/pki/pki-tomcat/logs

May 15, 2017 3:08:08 PM
org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NullPointerException

May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
loadOnStartup
SEVERE: Servlet [castart] in web application [/ca] threw load()
exception
java.lang.NullPointerException

May 15, 2017 3:08:09 PM
org.apache.catalina.core.StandardHostValve invoke
SEVERE: Exception Processing /ca/admin/ca/getStatus
javax.ws.rs <http://javax.ws.rs>
<http://javax.ws.rs>.ServiceUnavailableException: Subsystem
unavailable


Looking at the debug log it says Authentication failed for port 636.

[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
init begins
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
init ends
[15/May/2017:17:39:25][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
errorIfDown true
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert nickname to:
subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
client auth cert nickname subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: null
[15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake
happened
Could not connect to LDAP server host ipa12.mgmt.crosschx.com
<http://ipa12.mgmt.crosschx.com>
<http://ipa12.mgmt.crosschx.com
<http://ipa12.mgmt.crosschx.com>> port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
at

com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)


I looked at the validity of the cert it mentions and it is fine.

(root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n
'subsystemCert
cert-pki-ca'
State MONITORING, stuck: no.


I then looked at the ldap errors around the time of this failure
and I
am seeing this log entry.


[15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could
not get
initial credentials for principal
[ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
<mailto:ipa12.mgmt.crosschx@mgmt.crosschx.com>
<mailto:ipa12.mgmt.crosschx@mgmt.crosschx.com
<mailto:ipa12.mgmt.crosschx@mgmt.crosschx.com>>] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any
KDC for
requested realm)

When I perform a klist against that keytab nothing appears out
of the
ordinary compared to working IPA servers.

I am not sure what to look at next.


Hi,

you can try the following to manually replay the connection
established by Dogtag to LDAP server:

root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'

The above commands specify the NSSDB containing the user certificate
and its name for SASL-EXTERNAL authentication.

Then note the value obtained below as it will be used for the next
step as the password to access the private key in the NSSDB:
root$ grep internal /etc/pki/pki-tomcat/password.conf
internal=

root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
-Q -LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token
'ldap(0)':<<<< here supply the value found above
dn:
namingcontexts: cn=changelog
namingcontexts: dc=ipadomain,dc=com
namingcontexts: o=ipaca



So I guess I found my problem.

(root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for secur

Re: [Freeipa-users] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Florence Blanc-Renaud]

On 05/03/2017 05:16 PM, Chris Dagdigian wrote:



Any guidance for this one?

Summary - this seems to be the fatal error that causes the CA setup on
the replica to fail:

May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection:
The specified user cn=Replication Manager
masterAgreement1-usaeilidmp002.XXX.org-pki-tomcat,cn=config does not exist


May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init():
password test execution failed for replicationdbwith NO_SUCH_USER.  This
may not be a latest instance.  Ignoring ..


More details ...


Trying to build a replica with CA duties for the first time.

It hangs here during the replica install process:


ipa : DEBUGstderr=
ipa : DEBUGwait_for_open_ports: localhost [8080, 8443]
timeout 300
ipa : DEBUGWaiting until the CA is running
ipa : DEBUGrequest POST
http://usaeilidmp002.XXX.org:8080/ca/admin/ca/getStatus
ipa : DEBUGrequest body ''


However the root cause seems to be that the CA won't start because
something is wrong with an LDAP replication manager user?

When I restart the pki-tomcatd service the replica install STDOUT
refreshes the above status. After the 3rd attempt it triggers the fatal
"CA will not start after 300 seconds" error



From the logs:

# systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled;
vendor preset: disabled)
   Active: active (running) since Wed 2017-05-03 15:09:04 UTC; 40s ago
  Process: 3843 ExecStop=/usr/libexec/tomcat/server stop (code=exited,
status=1/FAILURE)
  Process: 3880 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited,
status=0/SUCCESS)
 Main PID: 3993 (java)
   CGroup:
/system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service
   └─3993 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java
-DRESTEASY_LIB=/usr/share/java/resteasy-base
-Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/...

May 03 15:09:08 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Setting container
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Initializing authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Starting authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore() begins
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore(): tag=internaldb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore(): tag=replicationdb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection:
The specified user cn=Replication Manager
masterAgreement1-usaeilidmp002.XXX...not exist
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init():
password test execution failed for replicationdbwith NO_SUCH_USER.  This
may not...noring ..
Hint: Some lines were ellipsized, use -l to show in full.







Hi,

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766

--
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 connect to LDAP server host - IO Error creating JSS SSL Socket:

[Florence Blanc-Renaud]

On 05/15/2017 08:33 PM, Michael Plemmons wrote:

I have done more searching in my logs and I see the following errors.

This is in the localhost log file /var/lib/pki/pki-tomcat/logs

May 15, 2017 3:08:08 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NullPointerException

May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
loadOnStartup
SEVERE: Servlet [castart] in web application [/ca] threw load() exception
java.lang.NullPointerException

May 15, 2017 3:08:09 PM org.apache.catalina.core.StandardHostValve invoke
SEVERE: Exception Processing /ca/admin/ca/getStatus
javax.ws.rs .ServiceUnavailableException: Subsystem
unavailable


Looking at the debug log it says Authentication failed for port 636.

[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init begins
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init ends
[15/May/2017:17:39:25][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
errorIfDown true
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert nickname to:
subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
client auth cert nickname subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: null
[15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host ipa12.mgmt.crosschx.com
 port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)


I looked at the validity of the cert it mentions and it is fine.

(root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
State MONITORING, stuck: no.


I then looked at the ldap errors around the time of this failure and I
am seeing this log entry.


[15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)

When I perform a klist against that keytab nothing appears out of the
ordinary compared to working IPA servers.

I am not sure what to look at next.



Hi,

you can try the following to manually replay the connection established 
by Dogtag to LDAP server:


root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'

The above commands specify the NSSDB containing the user certificate and 
its name for SASL-EXTERNAL authentication.


Then note the value obtained below as it will be used for the next step 
as the password to access the private key in the NSSDB:

root$ grep internal /etc/pki/pki-tomcat/password.conf
internal=

root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q 
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token 'ldap(0)': 
    here supply the value found above

dn:
namingcontexts: cn=changelog
namingcontexts: dc=ipadomain,dc=com
namingcontexts: o=ipaca


In the LDAP server access log (in 
/etc/dirsrv/slapd-IPADOMAIN.COM/access), you should see the 
corresponding connection:


[18/May/2017:13:35:14.822090417 +0200] conn=297 fd=150 slot=150 SSL 
connection from xxx to yyy
[18/May/2017:13:35:15.789414017 +0200] conn=297 TLS1.2 128-bit AES-GCM; 
client CN=CA Subsystem,O=IPADOMAIN.COM; issuer CN=Certificate 
Authority,O=IPADOMAIN.COM
[18/May/2017:13:35:15.793108509 +0200] conn=297 TLS1.2 client bound as 
uid=pkidbuser,ou=people,o=ipaca
[18/May/2017:13:35:15.798101505 +0200] conn=297 op=0 BIND dn="" 
method=sasl version=3 mech=EXTERNAL
[18/May/2017:13:35:15.800322076 +0200] conn=297 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca"


HTH,
Flo.





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX
*
614.427.2411
mike.plemm...@crosschx.com 
www.crosschx.com 

On Wed, May 10, 2017 at 3:35 PM, Michael Plemmons
>
wrote:

The PKI service came up successfully but only when it uses BasicAuth
rather than SSL auth.  I am not sure about what I need to do in
order to get the auth working over SSL again.

None of the certs are expired when I run getcert list and
ipa-getcert list.

Since the failure is with attempts to login to LDAP over 636.  I
have been attempting to auth to LDAP via port