subject:"Re\\\\\\\: \\\\\\\[Freeipa\\\\\\\-users\\\\\\\] IPA server having cert issues"

Re: [Freeipa-users] IPA server having cert issues

2016-04-29 Thread Bret Wortman

Scratch that. Decided to be daring and run "getcert resubmit -i" for 
each cert (after verifying the first one worked), then shut ipa down, 
advanced the date, re-enabled ntpd and started it back up. Looks clean.



On 04/29/2016 01:22 PM, Bret Wortman wrote:
Of course, I just remembered that the server still thinks it's April 
4, and I still have some certs that are expiring as of 4-17-16. Before 
I screw anything else up, what's the RIGHT way to renew those certs 
and move the server back to real time?




On 04/29/2016 01:07 PM, Bret Wortman wrote:

Hot damn! It's up and running.  Web UI works. CLI works.

The chgrp did the trick.

Thank you Rob, Petr and Christian!


Bret

On 04/29/2016 01:04 PM, Rob Crittenden wrote:

Bret Wortman wrote:

We run with selinux disabled.

# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other
services
ipa: INFO: The ipactl command was successful
#


The problem is permissions. Try:

# chgrp apache /etc/httpd/alias/*.db

The mode is ok, Apache only needs read access.

The segfault is fixed upstream and actual usable error messages 
reported. The init system doesn't see it as a failure because this 
happens after Apache forks its children.


I'd also consider re-enabling SELinux eventually.

rob





On 04/29/2016 12:25 PM, Christian Heimes wrote:

On 2016-04-29 18:17, Bret Wortman wrote:

I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0 ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 
conf.modules.d

lrwxrwxrwx  root root ? logs ->
../../var/log/httpd
lrwxrwxrwx  root root ? modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx  root root ? run -> /run/httpd
[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ? cacert.asc
-r--r--r--  root root   ? cacert.asc.orig
-rw-r-  root root   ? cert8.db
-rw-rw  root apache ? cert8.db.20160426
-rw-rw  root apache ? cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0 install.log
-rw-r-  root root   ? key3.db
-rw-rw  root apache ? key3.db.20160426
-rw-rw  root apache ? key3.db.orig
lrwxrwxrwx  root root   ? libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ? pwdfile.txt
-rw-rw  root apache ? pwdfile.txt.orig
-rw-rw  root apache ? secmod.db
-rw-rw  root apache ? secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You 
should see

a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache 
HTTPD again.


Christian













--
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 having cert issues

2016-04-29 Thread Bret Wortman

Of course, I just remembered that the server still thinks it's April 4, 
and I still have some certs that are expiring as of 4-17-16. Before I 
screw anything else up, what's the RIGHT way to renew those certs and 
move the server back to real time?




On 04/29/2016 01:07 PM, Bret Wortman wrote:

Hot damn! It's up and running.  Web UI works. CLI works.

The chgrp did the trick.

Thank you Rob, Petr and Christian!


Bret

On 04/29/2016 01:04 PM, Rob Crittenden wrote:

Bret Wortman wrote:

We run with selinux disabled.

# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other
services
ipa: INFO: The ipactl command was successful
#


The problem is permissions. Try:

# chgrp apache /etc/httpd/alias/*.db

The mode is ok, Apache only needs read access.

The segfault is fixed upstream and actual usable error messages 
reported. The init system doesn't see it as a failure because this 
happens after Apache forks its children.


I'd also consider re-enabling SELinux eventually.

rob





On 04/29/2016 12:25 PM, Christian Heimes wrote:

On 2016-04-29 18:17, Bret Wortman wrote:

I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 
conf.modules.d

lrwxrwxrwx  root root ? logs ->
../../var/log/httpd
lrwxrwxrwx  root root ? modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx  root root ?run -> 
/run/httpd

[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ? cacert.asc
-r--r--r--  root root   ? cacert.asc.orig
-rw-r-  root root   ? cert8.db
-rw-rw  root apache ? cert8.db.20160426
-rw-rw  root apache ? cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0 install.log
-rw-r-  root root   ? key3.db
-rw-rw  root apache ? key3.db.20160426
-rw-rw  root apache ? key3.db.orig
lrwxrwxrwx  root root   ? libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ? pwdfile.txt
-rw-rw  root apache ? pwdfile.txt.orig
-rw-rw  root apache ? secmod.db
-rw-rw  root apache ? secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You 
should see

a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache 
HTTPD again.


Christian











--
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 having cert issues

2016-04-29 Thread Bret Wortman


Hot damn! It's up and running.  Web UI works. CLI works.

The chgrp did the trick.

Thank you Rob, Petr and Christian!


Bret

On 04/29/2016 01:04 PM, Rob Crittenden wrote:

Bret Wortman wrote:

We run with selinux disabled.

# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other
services
ipa: INFO: The ipactl command was successful
#


The problem is permissions. Try:

# chgrp apache /etc/httpd/alias/*.db

The mode is ok, Apache only needs read access.

The segfault is fixed upstream and actual usable error messages 
reported. The init system doesn't see it as a failure because this 
happens after Apache forks its children.


I'd also consider re-enabling SELinux eventually.

rob





On 04/29/2016 12:25 PM, Christian Heimes wrote:

On 2016-04-29 18:17, Bret Wortman wrote:

I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0  alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 
conf.modules.d

lrwxrwxrwx  root root ?logs ->
../../var/log/httpd
lrwxrwxrwx  root root ? modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx  root root ?run -> 
/run/httpd

[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
drwxr-xr-x. root root   system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ? cacert.asc
-r--r--r--  root root   ? cacert.asc.orig
-rw-r-  root root   ? cert8.db
-rw-rw  root apache ? cert8.db.20160426
-rw-rw  root apache ? cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0 install.log
-rw-r-  root root   ? key3.db
-rw-rw  root apache ? key3.db.20160426
-rw-rw  root apache ? key3.db.orig
lrwxrwxrwx  root root   ? libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ? pwdfile.txt
-rw-rw  root apache ? pwdfile.txt.orig
-rw-rw  root apache ? secmod.db
-rw-rw  root apache ? secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You should 
see

a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache HTTPD 
again.


Christian









--
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 having cert issues

2016-04-29 Thread Rob Crittenden


Bret Wortman wrote:

We run with selinux disabled.

# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other
services
ipa: INFO: The ipactl command was successful
#


The problem is permissions. Try:

# chgrp apache /etc/httpd/alias/*.db

The mode is ok, Apache only needs read access.

The segfault is fixed upstream and actual usable error messages 
reported. The init system doesn't see it as a failure because this 
happens after Apache forks its children.


I'd also consider re-enabling SELinux eventually.

rob





On 04/29/2016 12:25 PM, Christian Heimes wrote:

On 2016-04-29 18:17, Bret Wortman wrote:

I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0  alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.modules.d
lrwxrwxrwx  root root ?logs ->
../../var/log/httpd
lrwxrwxrwx  root root ?modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx  root root ?run -> /run/httpd
[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
drwxr-xr-x. root root   system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ?cacert.asc
-r--r--r--  root root   ?cacert.asc.orig
-rw-r-  root root   ?cert8.db
-rw-rw  root apache ?cert8.db.20160426
-rw-rw  root apache ?cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0  install.log
-rw-r-  root root   ?key3.db
-rw-rw  root apache ?key3.db.20160426
-rw-rw  root apache ?key3.db.orig
lrwxrwxrwx  root root   ?libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ?pwdfile.txt
-rw-rw  root apache ?pwdfile.txt.orig
-rw-rw  root apache ?secmod.db
-rw-rw  root apache ?secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You should see
a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache HTTPD again.

Christian







--
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 having cert issues

2016-04-29 Thread Bret Wortman


We run with selinux disabled.

# getenforce
Disabled
# restorecon -R -v /etc/httpd/alias
# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other 
services

ipa: INFO: The ipactl command was successful
#



On 04/29/2016 12:25 PM, Christian Heimes wrote:

On 2016-04-29 18:17, Bret Wortman wrote:

I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0  alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.modules.d
lrwxrwxrwx  root root ?logs ->
../../var/log/httpd
lrwxrwxrwx  root root ?modules ->
../../usr/lib64/httpd/modules
lrwxrwxrwx  root root ?run -> /run/httpd
[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
drwxr-xr-x. root root   system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ?cacert.asc
-r--r--r--  root root   ?cacert.asc.orig
-rw-r-  root root   ?cert8.db
-rw-rw  root apache ?cert8.db.20160426
-rw-rw  root apache ?cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0  install.log
-rw-r-  root root   ?key3.db
-rw-rw  root apache ?key3.db.20160426
-rw-rw  root apache ?key3.db.orig
lrwxrwxrwx  root root   ?libnssckbi.so
-> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ?pwdfile.txt
-rw-rw  root apache ?pwdfile.txt.orig
-rw-rw  root apache ?secmod.db
-rw-rw  root apache ?secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You should see
a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache HTTPD again.

Christian



-- 
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 having cert issues

2016-04-29 Thread Christian Heimes

On 2016-04-29 18:17, Bret Wortman wrote:
> I'll put the results inline here, since they're short.
> 
> [root@zsipa log]# ls -laZ /etc/httpd/
> drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
> drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
> drwxr-xr-x. root root system_u:object_r:cert_t:s0  alias
> drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
> drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
> drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.modules.d
> lrwxrwxrwx  root root ?logs ->
> ../../var/log/httpd
> lrwxrwxrwx  root root ?modules ->
> ../../usr/lib64/httpd/modules
> lrwxrwxrwx  root root ?run -> /run/httpd
> [root@zsipa log]# ls -laZ /etc/httpd/alias
> drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
> drwxr-xr-x. root root   system_u:object_r:httpd_config_t:s0 ..
> -r--r--r--  root root   ?cacert.asc
> -r--r--r--  root root   ?cacert.asc.orig
> -rw-r-  root root   ?cert8.db
> -rw-rw  root apache ?cert8.db.20160426
> -rw-rw  root apache ?cert8.db.orig
> -rw---. root root   system_u:object_r:cert_t:s0  install.log
> -rw-r-  root root   ?key3.db
> -rw-rw  root apache ?key3.db.20160426
> -rw-rw  root apache ?key3.db.orig
> lrwxrwxrwx  root root   ?libnssckbi.so
> -> ../../..//usr/lib64/libnssckbi.so
> -rw-rw  root apache ?pwdfile.txt
> -rw-rw  root apache ?pwdfile.txt.orig
> -rw-rw  root apache ?secmod.db
> -rw-rw  root apache ?secmod.db.orig

Some files don't have the correct SELinux context or are completely
missing a context. SELinux prevents Apache from accessing this files.
Did you replace some files or restore some from a backup? You should see
a bunch of SELinux violations in your audit log.

In order to restore the correct context, please run restorecon:

# restorecon -R -v /etc/httpd/alias

This should set correct contexts and allow you to start Apache HTTPD again.

Christian



signature.asc
Description: OpenPGP digital 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 server having cert issues

2016-04-29 Thread Bret Wortman


I'll put the results inline here, since they're short.

[root@zsipa log]# ls -laZ /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0   ..
drwxr-xr-x. root root system_u:object_r:cert_t:s0  alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.modules.d
lrwxrwxrwx  root root ?logs -> 
../../var/log/httpd
lrwxrwxrwx  root root ?modules -> 
../../usr/lib64/httpd/modules

lrwxrwxrwx  root root ?run -> /run/httpd
[root@zsipa log]# ls -laZ /etc/httpd/alias
drwxr-xr-x. root root   system_u:object_r:cert_t:s0  .
drwxr-xr-x. root root   system_u:object_r:httpd_config_t:s0 ..
-r--r--r--  root root   ? cacert.asc
-r--r--r--  root root   ? cacert.asc.orig
-rw-r-  root root   ?cert8.db
-rw-rw  root apache ? cert8.db.20160426
-rw-rw  root apache ? cert8.db.orig
-rw---. root root   system_u:object_r:cert_t:s0 install.log
-rw-r-  root root   ?key3.db
-rw-rw  root apache ? key3.db.20160426
-rw-rw  root apache ? key3.db.orig
lrwxrwxrwx  root root   ? libnssckbi.so -> ../../..//usr/lib64/libnssckbi.so
-rw-rw  root apache ? pwdfile.txt
-rw-rw  root apache ? pwdfile.txt.orig
-rw-rw  root apache ?secmod.db
-rw-rw  root apache ? secmod.db.orig
[root@zsipa log]# certutil -L -d /etc/httpd/alias

Certificate Nickname Trust 
Attributes

SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
Server-Cert  u,u,u
ipaCert  u,u,u
PRIVATE.NET IPA CA CT,C,C
PRIVATE.NET IPA CA CT,C,C
[root@zsipa log]#


On 04/29/2016 11:02 AM, Christian Heimes wrote:

On 2016-04-29 16:51, Bret Wortman wrote:

It is contacting the correct machine. I tried again by IP with the same
results.

/etc/httpd/conf.d/ipa-pki-proxy.conf is dated May 20 2014.

Web UI won't load. CLI won't respond either. Commands just hang.

# netstat -ln | grep 443
tcp6   0 0 :::8443
:::* LISTEN
tcp6   2 0 :::443
:::* LISTEN
# netstat -ln | grep 8009
tcp6   0 0 127.0.0.1:8009
:::* LISTEN
# curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus
* Hostname was NOT found in DNS cache
*   Trying 192.168.208.53...
* Connected to zsipa.private.net (192.168.208.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
   CApath: none
(long hang at this point, so I ^C-ed)

# openssl s_client -connect zsipa.private.net:443 -CAfile
/etc/ipa/ca.crt -verify 10
verify depth is 10
CONNECTED(0003)
(long hang at this point, aborted again)

For the other (longer) logs, see http://pastebin.com/esBBKyGZ

Also, answering Christian's questions:

mod_ssl has not been installed.

# ss -tpln | grep 443
LISTEN  0   100:::8443   :::*
users:(("java",pid=26522,fd=84))
LISTEN  13  128:::443:::*
users:(("httpd",pid=26323,fd=6))
#

The output of ss looks sane. httpd is Apache, Java is Dogtag PKI's
Tomcat instance.

The error log of Apache is more troublesome. It looks like your NSSDB is
busted:

[Mon Apr 04 14:18:49.330238 2016] [:error] [pid 26327] NSS_Initialize
failed. Certificate database: /etc/httpd/alias.
[Mon Apr 04 14:18:49.330253 2016] [:error] [pid 26327] SSL Library
Error: -8038 SEC_ERROR_NOT_INITIALIZED
[Mon Apr 04 14:18:50.318327 2016] [core:notice] [pid 26323] AH00052:
child pid 26327 exit signal Segmentation fault (11)

Please run this commands to show us the content of your NSSDB.

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


Christian



-- 
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 having cert issues

2016-04-29 Thread Christian Heimes

On 2016-04-29 16:51, Bret Wortman wrote:
> It is contacting the correct machine. I tried again by IP with the same
> results.
> 
> /etc/httpd/conf.d/ipa-pki-proxy.conf is dated May 20 2014.
> 
> Web UI won't load. CLI won't respond either. Commands just hang.
> 
> # netstat -ln | grep 443
> tcp6   0 0 :::8443  
> :::* LISTEN
> tcp6   2 0 :::443   
> :::* LISTEN
> # netstat -ln | grep 8009
> tcp6   0 0 127.0.0.1:8009   
> :::* LISTEN
> # curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus
> * Hostname was NOT found in DNS cache
> *   Trying 192.168.208.53...
> * Connected to zsipa.private.net (192.168.208.53) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>   CApath: none
> (long hang at this point, so I ^C-ed)
> 
> # openssl s_client -connect zsipa.private.net:443 -CAfile
> /etc/ipa/ca.crt -verify 10
> verify depth is 10
> CONNECTED(0003)
> (long hang at this point, aborted again)
> 
> For the other (longer) logs, see http://pastebin.com/esBBKyGZ
> 
> Also, answering Christian's questions:
> 
> mod_ssl has not been installed.
> 
> # ss -tpln | grep 443
> LISTEN  0   100:::8443   :::*
> users:(("java",pid=26522,fd=84))
> LISTEN  13  128:::443:::*
> users:(("httpd",pid=26323,fd=6))
> #

The output of ss looks sane. httpd is Apache, Java is Dogtag PKI's
Tomcat instance.

The error log of Apache is more troublesome. It looks like your NSSDB is
busted:

[Mon Apr 04 14:18:49.330238 2016] [:error] [pid 26327] NSS_Initialize
failed. Certificate database: /etc/httpd/alias.
[Mon Apr 04 14:18:49.330253 2016] [:error] [pid 26327] SSL Library
Error: -8038 SEC_ERROR_NOT_INITIALIZED
[Mon Apr 04 14:18:50.318327 2016] [core:notice] [pid 26323] AH00052:
child pid 26327 exit signal Segmentation fault (11)

Please run this commands to show us the content of your NSSDB.

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


Christian



signature.asc
Description: OpenPGP digital 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 server having cert issues

2016-04-29 Thread Bret Wortman

It is contacting the correct machine. I tried again by IP with the same 
results.


/etc/httpd/conf.d/ipa-pki-proxy.conf is dated May 20 2014.

Web UI won't load. CLI won't respond either. Commands just hang.

# netstat -ln | grep 443
tcp6   0 0 :::8443 :::* LISTEN
tcp6   2 0 :::443:::* LISTEN
# netstat -ln | grep 8009
tcp6   0 0 127.0.0.1:8009 :::* LISTEN
# curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus
* Hostname was NOT found in DNS cache
*   Trying 192.168.208.53...
* Connected to zsipa.private.net (192.168.208.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
(long hang at this point, so I ^C-ed)

# openssl s_client -connect zsipa.private.net:443 -CAfile 
/etc/ipa/ca.crt -verify 10

verify depth is 10
CONNECTED(0003)
(long hang at this point, aborted again)

For the other (longer) logs, see http://pastebin.com/esBBKyGZ

Also, answering Christian's questions:

mod_ssl has not been installed.

# ss -tpln | grep 443
LISTEN  0   100:::8443   :::*
users:(("java",pid=26522,fd=84))
LISTEN  13  128:::443:::*
users:(("httpd",pid=26323,fd=6))
#

On 04/29/2016 10:08 AM, Petr Vobornik wrote:

On 04/29/2016 02:53 PM, Bret Wortman wrote:

Despite "ipactl status" indicating that all processes were running after
step 1, step 2 produces "Unable to establish SSL connection."

Full terminal session is at http://pastebin.com/ZuNBHPy0

Hm, it doesn't help me much.

Does it contact the correct machine? I.e., is IP address OK?

What is the result of:

netstat -ln | grep 443
netstat -ln | grep 8009

Have you modified by any chance: /etc/httpd/conf.d/ipa-pki-proxy.conf

Try to run curl, maybe it will be more verbose, but probably not:

   # curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus

Christian(CCd), do you have any ideas?

Could you look into /var/log/httpd/error_log or syslog(would try
/var/log/message and journalctl), There might be more information about the:
"""
status: NEED_TO_SUBMIT
ca-error: Internal error
"""
Which may help us with root culprit.

Do web ui or CLI work?


On 04/29/2016 07:29 AM, Petr Vobornik wrote:

On 04/29/2016 12:03 PM, Bret Wortman wrote:

The date change was due (I think) to me changing the date back to 4/1
yesterday, though I left it there and haven't updated it again until
this morning, when I went back to 4/1 again.

I put the results of the commands you requested at
https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really
appreciate it.


Bret

If I combine this and the previous output, it seems that:

- PKI starts normally
- ipactl has troubles with determining that PKI started and after 5mins
of failed attempts it stops whole IPA (expected behavior when a service
doesn't start)

The failed attempt is:
"""
ipa: DEBUG: Waiting until the CA is running
ipa: DEBUG: Starting external process
ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
'--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'
ipa: DEBUG: Process finished, return code=4
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=--2016-04-01 09:39:50--
https://zsipa.private.net/ca/admin/ca/getStatus
Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53
Connecting to zsipa.private.net
(zsipa.private.net)|192.168.208.53|:443... connected.
Unable to establish SSL connection.

ipa: DEBUG: The CA status is: check interrupted due to error: Command
''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero
exit status 4
"""

It says "Unable to establish SSL connection", it would be good to get
more details.

Also given that the CA cert was renewed on April 3rd and that all certs
expires after that date, we should rather use date April 4th when moving
the date back.

So first start IPA again (date April 4th) but force it to not stop
services

1. ipactl start --force
wait until all is started
2. wget -v -d -S -O - --timeout=30 --no-check-certificate
https://zsipa.private.net:443/ca/admin/ca/getStatus

optionally (assuming that CA won't be turned of)
3. getcert list





-- 
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 having cert issues

2016-04-29 Thread Christian Heimes

On 2016-04-29 16:08, Petr Vobornik wrote:
> On 04/29/2016 02:53 PM, Bret Wortman wrote:
>> Despite "ipactl status" indicating that all processes were running after
>> step 1, step 2 produces "Unable to establish SSL connection."
>>
>> Full terminal session is at http://pastebin.com/ZuNBHPy0
> 
> Hm, it doesn't help me much.
> 
> Does it contact the correct machine? I.e., is IP address OK?
> 
> What is the result of:
> 
> netstat -ln | grep 443
> netstat -ln | grep 8009
> 
> Have you modified by any chance: /etc/httpd/conf.d/ipa-pki-proxy.conf
> 
> Try to run curl, maybe it will be more verbose, but probably not:
> 
>   # curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus
> 
> Christian(CCd), do you have any ideas?

Is Apache HTTPD running and listening on 443/TCP?

$ ss -tpln | grep 443

Did you install mod_ssl by any chance? FreeIPA uses mod_nss. mod_ssl can
disrupt TLS services.


The openssl client tool shows more debug information than curl:

openssl s_client -connect zsipa.private.net:443 -CAfile /etc/ipa/ca.crt
-verify 10

Christian



signature.asc
Description: OpenPGP digital 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 server having cert issues

2016-04-29 Thread Petr Vobornik

On 04/29/2016 02:53 PM, Bret Wortman wrote:
> Despite "ipactl status" indicating that all processes were running after
> step 1, step 2 produces "Unable to establish SSL connection."
> 
> Full terminal session is at http://pastebin.com/ZuNBHPy0

Hm, it doesn't help me much.

Does it contact the correct machine? I.e., is IP address OK?

What is the result of:

netstat -ln | grep 443
netstat -ln | grep 8009

Have you modified by any chance: /etc/httpd/conf.d/ipa-pki-proxy.conf

Try to run curl, maybe it will be more verbose, but probably not:

  # curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus

Christian(CCd), do you have any ideas?

Could you look into /var/log/httpd/error_log or syslog(would try
/var/log/message and journalctl), There might be more information about the:
"""
status: NEED_TO_SUBMIT
ca-error: Internal error
"""
Which may help us with root culprit.

Do web ui or CLI work?

> 
> On 04/29/2016 07:29 AM, Petr Vobornik wrote:
>> On 04/29/2016 12:03 PM, Bret Wortman wrote:
>>> The date change was due (I think) to me changing the date back to 4/1
>>> yesterday, though I left it there and haven't updated it again until
>>> this morning, when I went back to 4/1 again.
>>>
>>> I put the results of the commands you requested at
>>> https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really
>>> appreciate it.
>>>
>>>
>>> Bret
>> If I combine this and the previous output, it seems that:
>>
>> - PKI starts normally
>> - ipactl has troubles with determining that PKI started and after 5mins
>> of failed attempts it stops whole IPA (expected behavior when a service
>> doesn't start)
>>
>> The failed attempt is:
>> """
>> ipa: DEBUG: Waiting until the CA is running
>> ipa: DEBUG: Starting external process
>> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
>> '--no-check-certificate'
>> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'
>> ipa: DEBUG: Process finished, return code=4
>> ipa: DEBUG: stdout=
>> ipa: DEBUG: stderr=--2016-04-01 09:39:50--
>> https://zsipa.private.net/ca/admin/ca/getStatus
>> Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53
>> Connecting to zsipa.private.net
>> (zsipa.private.net)|192.168.208.53|:443... connected.
>> Unable to establish SSL connection.
>>
>> ipa: DEBUG: The CA status is: check interrupted due to error: Command
>> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
>> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero
>> exit status 4
>> """
>>
>> It says "Unable to establish SSL connection", it would be good to get
>> more details.
>>
>> Also given that the CA cert was renewed on April 3rd and that all certs
>> expires after that date, we should rather use date April 4th when moving
>> the date back.
>>
>> So first start IPA again (date April 4th) but force it to not stop
>> services
>>
>> 1. ipactl start --force
>> wait until all is started
>> 2. wget -v -d -S -O - --timeout=30 --no-check-certificate
>> https://zsipa.private.net:443/ca/admin/ca/getStatus
>>
>> optionally (assuming that CA won't be turned of)
>> 3. getcert list
>>
> 


-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-29 Thread Petr Vobornik

On 04/29/2016 02:53 PM, Bret Wortman wrote:
> Despite "ipactl status" indicating that all processes were running after
> step 1, step 2 produces "Unable to establish SSL connection."
> 
> Full terminal session is at http://pastebin.com/ZuNBHPy0
> 
> On 04/29/2016 07:29 AM, Petr Vobornik wrote:
>> On 04/29/2016 12:03 PM, Bret Wortman wrote:
>>> The date change was due (I think) to me changing the date back to 4/1
>>> yesterday, though I left it there and haven't updated it again until
>>> this morning, when I went back to 4/1 again.
>>>
>>> I put the results of the commands you requested at
>>> https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really
>>> appreciate it.

I cannot view the pastebin:
"""
This is a private paste. If you created this paste, please login to view it.
"""

>>>
>>>
>>> Bret
>> If I combine this and the previous output, it seems that:
>>
>> - PKI starts normally
>> - ipactl has troubles with determining that PKI started and after 5mins
>> of failed attempts it stops whole IPA (expected behavior when a service
>> doesn't start)
>>
>> The failed attempt is:
>> """
>> ipa: DEBUG: Waiting until the CA is running
>> ipa: DEBUG: Starting external process
>> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
>> '--no-check-certificate'
>> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'
>> ipa: DEBUG: Process finished, return code=4
>> ipa: DEBUG: stdout=
>> ipa: DEBUG: stderr=--2016-04-01 09:39:50--
>> https://zsipa.private.net/ca/admin/ca/getStatus
>> Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53
>> Connecting to zsipa.private.net
>> (zsipa.private.net)|192.168.208.53|:443... connected.
>> Unable to establish SSL connection.
>>
>> ipa: DEBUG: The CA status is: check interrupted due to error: Command
>> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
>> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero
>> exit status 4
>> """
>>
>> It says "Unable to establish SSL connection", it would be good to get
>> more details.
>>
>> Also given that the CA cert was renewed on April 3rd and that all certs
>> expires after that date, we should rather use date April 4th when moving
>> the date back.
>>
>> So first start IPA again (date April 4th) but force it to not stop
>> services
>>
>> 1. ipactl start --force
>> wait until all is started
>> 2. wget -v -d -S -O - --timeout=30 --no-check-certificate
>> https://zsipa.private.net:443/ca/admin/ca/getStatus
>>
>> optionally (assuming that CA won't be turned of)
>> 3. getcert list
>>
> 


-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-29 Thread Bret Wortman

Despite "ipactl status" indicating that all processes were running after 
step 1, step 2 produces "Unable to establish SSL connection."


Full terminal session is at http://pastebin.com/ZuNBHPy0

On 04/29/2016 07:29 AM, Petr Vobornik wrote:

On 04/29/2016 12:03 PM, Bret Wortman wrote:

The date change was due (I think) to me changing the date back to 4/1
yesterday, though I left it there and haven't updated it again until
this morning, when I went back to 4/1 again.

I put the results of the commands you requested at
https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really
appreciate it.


Bret

If I combine this and the previous output, it seems that:

- PKI starts normally
- ipactl has troubles with determining that PKI started and after 5mins
of failed attempts it stops whole IPA (expected behavior when a service
doesn't start)

The failed attempt is:
"""
ipa: DEBUG: Waiting until the CA is running
ipa: DEBUG: Starting external process
ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
'--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'
ipa: DEBUG: Process finished, return code=4
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=--2016-04-01 09:39:50--
https://zsipa.private.net/ca/admin/ca/getStatus
Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53
Connecting to zsipa.private.net
(zsipa.private.net)|192.168.208.53|:443... connected.
Unable to establish SSL connection.

ipa: DEBUG: The CA status is: check interrupted due to error: Command
''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero
exit status 4
"""

It says "Unable to establish SSL connection", it would be good to get
more details.

Also given that the CA cert was renewed on April 3rd and that all certs
expires after that date, we should rather use date April 4th when moving
the date back.

So first start IPA again (date April 4th) but force it to not stop services

1. ipactl start --force
wait until all is started
2. wget -v -d -S -O - --timeout=30 --no-check-certificate
https://zsipa.private.net:443/ca/admin/ca/getStatus

optionally (assuming that CA won't be turned of)
3. getcert list



--
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 having cert issues

2016-04-29 Thread Petr Vobornik

On 04/29/2016 12:03 PM, Bret Wortman wrote:
> The date change was due (I think) to me changing the date back to 4/1
> yesterday, though I left it there and haven't updated it again until
> this morning, when I went back to 4/1 again.
> 
> I put the results of the commands you requested at
> https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really
> appreciate it.
> 
> 
> Bret

If I combine this and the previous output, it seems that:

- PKI starts normally
- ipactl has troubles with determining that PKI started and after 5mins
of failed attempts it stops whole IPA (expected behavior when a service
doesn't start)

The failed attempt is:
"""
ipa: DEBUG: Waiting until the CA is running
ipa: DEBUG: Starting external process
ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
'--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'
ipa: DEBUG: Process finished, return code=4
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=--2016-04-01 09:39:50--
https://zsipa.private.net/ca/admin/ca/getStatus
Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53
Connecting to zsipa.private.net
(zsipa.private.net)|192.168.208.53|:443... connected.
Unable to establish SSL connection.

ipa: DEBUG: The CA status is: check interrupted due to error: Command
''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero
exit status 4
"""

It says "Unable to establish SSL connection", it would be good to get
more details.

Also given that the CA cert was renewed on April 3rd and that all certs
expires after that date, we should rather use date April 4th when moving
the date back.

So first start IPA again (date April 4th) but force it to not stop services

1. ipactl start --force
wait until all is started
2. wget -v -d -S -O - --timeout=30 --no-check-certificate
https://zsipa.private.net:443/ca/admin/ca/getStatus

optionally (assuming that CA won't be turned of)
3. getcert list

-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-29 Thread Bret Wortman

The date change was due (I think) to me changing the date back to 4/1 
yesterday, though I left it there and haven't updated it again until 
this morning, when I went back to 4/1 again.


I put the results of the commands you requested at 
https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really 
appreciate it.



Bret

On 04/29/2016 04:59 AM, Petr Vobornik wrote:

comments inline

On 04/28/2016 06:30 PM, Bret Wortman wrote:

Look, I'll be honest. When IPA is in this much of a knot, I don't know how to do
the simplest things with its various components. For example, I've no clue how
to search the ldap database for anything. Or even how to authenticate since
Kerberos isn't running. IPA has sheltered me from ldap for so long that it's a
problem at times like this.

That being said, here are the things I /was/ able to handle:

Apr 01 11:02:40 zsipa.private.net server[6896]: Java virtual machine used:
/usr/lib/jvm/jre/bin/java
Apr 01 11:02:40 zsipa.private.net server[6896]: classpath used:
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.j
Apr 01 11:02:40 zsipa.private.net server[6896]: main class used:
org.apache.catalina.startup.Bootstrap
Apr 01 11:02:40 zsipa.private.net server[6896]: flags used:
-DRESTEASY_LIB=/usr/share/java/resteasy
Apr 01 11:02:40 zsipa.private.net server[6896]: options used:
-Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.
Apr 01 11:02:40 zsipa.private.net server[6896]: arguments used: start
Apr 01 11:02:40 zsipa.private.net server[6896]: Apr 01, 2016 11:02:40 AM
org.apache.catalina.startup.ClassLoaderFactory validateFile
Apr 01 11:02:40 zsipa.private.net server[6896]: WARNING: Problem with JAR file
[/var/lib/pki/pki-tomcat/lib/log4j.jar], exists: [false], canRead: [false]
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP'
to 'false' did not find a matchi
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderURL' to 'http://zsipa.private.net:9
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderCertNickname' to 'ocspSigningCe
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspCacheSize' to '1000' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMinCacheEntryDuration' to '60' did not f
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMaxCacheEntryDuration' to '120' did not
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspTimeout'
to '10' did not find a matching
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property
'strictCiphers' to 'true' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslOptions'
to 'ssl2=true,ssl3=true,tls=true
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING:
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ssl2Ciphers'
to '-SSL2_RC4_128_WITH_MD5,-SSL
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]:

Re: [Freeipa-users] IPA server having cert issues

2016-04-29 Thread Petr Vobornik

comments inline

On 04/28/2016 06:30 PM, Bret Wortman wrote:
> Look, I'll be honest. When IPA is in this much of a knot, I don't know how to 
> do 
> the simplest things with its various components. For example, I've no clue 
> how 
> to search the ldap database for anything. Or even how to authenticate since 
> Kerberos isn't running. IPA has sheltered me from ldap for so long that it's 
> a 
> problem at times like this.
> 
> That being said, here are the things I /was/ able to handle:
> 
> Apr 01 11:02:40 zsipa.private.net server[6896]: Java virtual machine used: 
> /usr/lib/jvm/jre/bin/java
> Apr 01 11:02:40 zsipa.private.net server[6896]: classpath used: 
> /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.j
> Apr 01 11:02:40 zsipa.private.net server[6896]: main class used: 
> org.apache.catalina.startup.Bootstrap
> Apr 01 11:02:40 zsipa.private.net server[6896]: flags used: 
> -DRESTEASY_LIB=/usr/share/java/resteasy
> Apr 01 11:02:40 zsipa.private.net server[6896]: options used: 
> -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat 
> -Djava.endorsed.dirs= -Djava.io.
> Apr 01 11:02:40 zsipa.private.net server[6896]: arguments used: start
> Apr 01 11:02:40 zsipa.private.net server[6896]: Apr 01, 2016 11:02:40 AM 
> org.apache.catalina.startup.ClassLoaderFactory validateFile
> Apr 01 11:02:40 zsipa.private.net server[6896]: WARNING: Problem with JAR 
> file 
> [/var/lib/pki/pki-tomcat/lib/log4j.jar], exists: [false], canRead: [false]
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'enableOCSP' 
> to 'false' did not find a matchi
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspResponderURL' to 'http://zsipa.private.net:9
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspResponderCertNickname' to 'ocspSigningCe
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspCacheSize' to '1000' did not find a matc
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspMinCacheEntryDuration' to '60' did not f
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspMaxCacheEntryDuration' to '120' did not
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ocspTimeout' 
> to '10' did not find a matching
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'strictCiphers' to 'true' did not find a matc
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'sslOptions' 
> to 'ssl2=true,ssl3=true,tls=true
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ssl2Ciphers' 
> to '-SSL2_RC4_128_WITH_MD5,-SSL
> Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property 
> 'ssl3Ciphers' 
> to '-SSL3_FORTEZZA_DMS_WITH_NUL
> Apr 01 11:02:41

Re: [Freeipa-users] IPA server having cert issues

2016-04-28 Thread Bret Wortman

Okay, I ran 'ldapsearch -x -h zsipa -p 389 -b 'ou=people,o=ipaca' and 
dumped that to a file. I'm still not clear on what I'm supposed to be 
looking for in the output, though.


The result of systemctl | grep dirsrv@ was pretty uninformative. If the 
answer was "dirsrv", then I don't find that in the ldapsearch results. 
Assuming that was the ldapsearch command I needed to run


On 04/28/2016 12:04 PM, Petr Vobornik wrote:

On 04/28/2016 05:49 PM, Bret Wortman wrote:

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
have the pki-server binary itself. Will reinstalling this rpm hurt me in
any way? Without it, I'm not sure how to check my system against the
messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
   systemctl status  pki-tomcatd@pki-tomcat.service
   journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
   systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
   systemctl | grep dirsrv@



On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It
didn't
work, but I got something new and interesting in the debug log, which
I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html


On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
looks
logical to me, but I can't spot anything that looks like a root
cause error.
The selftests are all okay, I think. The debug log might have
something, but
it might also just be complaining about ldap not being up because
it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for
messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]







--
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 having cert issues

2016-04-28 Thread Bret Wortman

Look, I'll be honest. When IPA is in this much of a knot, I don't know 
how to do the simplest things with its various components. For example, 
I've no clue how to search the ldap database for anything. Or even how 
to authenticate since Kerberos isn't running. IPA has sheltered me from 
ldap for so long that it's a problem at times like this.


That being said, here are the things I /was/ able to handle:

Apr 01 11:02:40 zsipa.private.net server[6896]: Java virtual machine 
used: /usr/lib/jvm/jre/bin/java
Apr 01 11:02:40 zsipa.private.net server[6896]: classpath used: 
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.j
Apr 01 11:02:40 zsipa.private.net server[6896]: main class used: 
org.apache.catalina.startup.Bootstrap
Apr 01 11:02:40 zsipa.private.net server[6896]: flags used: 
-DRESTEASY_LIB=/usr/share/java/resteasy
Apr 01 11:02:40 zsipa.private.net server[6896]: options used: 
-Dcatalina.base=/var/lib/pki/pki-tomcat 
-Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.

Apr 01 11:02:40 zsipa.private.net server[6896]: arguments used: start
Apr 01 11:02:40 zsipa.private.net server[6896]: Apr 01, 2016 11:02:40 AM 
org.apache.catalina.startup.ClassLoaderFactory validateFile
Apr 01 11:02:40 zsipa.private.net server[6896]: WARNING: Problem with 
JAR file [/var/lib/pki/pki-tomcat/lib/log4j.jar], exists: [false], 
canRead: [false]
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'enableOCSP' to 'false' did not find a matchi
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderURL' to 'http://zsipa.private.net:9
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderCertNickname' to 'ocspSigningCe
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspCacheSize' to '1000' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMinCacheEntryDuration' to '60' did not f
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMaxCacheEntryDuration' to '120' did not
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspTimeout' to '10' did not find a matching
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'strictCiphers' to 'true' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'sslOptions' to 'ssl2=true,ssl3=true,tls=true
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ssl2Ciphers' to '-SSL2_RC4_128_WITH_MD5,-SSL
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ssl3Ciphers' to '-SSL3_FORTEZZA_DMS_WITH_NUL
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'tlsCiphers' to

Re: [Freeipa-users] IPA server having cert issues

2016-04-28 Thread Bret Wortman

Okay. I got hung up on the first link doing some checking using 
pki-server. I don't see any reference to ldapsearch in either message, 
but I'll do what I can.



On 04/28/2016 12:04 PM, Petr Vobornik wrote:

On 04/28/2016 05:49 PM, Bret Wortman wrote:

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
have the pki-server binary itself. Will reinstalling this rpm hurt me in
any way? Without it, I'm not sure how to check my system against the
messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
   systemctl status  pki-tomcatd@pki-tomcat.service
   journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
   systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
   systemctl | grep dirsrv@



On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It
didn't
work, but I got something new and interesting in the debug log, which
I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html


On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
looks
logical to me, but I can't spot anything that looks like a root
cause error.
The selftests are all okay, I think. The debug log might have
something, but
it might also just be complaining about ldap not being up because
it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for
messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]







--
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 having cert issues

2016-04-28 Thread Petr Vobornik

On 04/28/2016 05:49 PM, Bret Wortman wrote:
> My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
> have the pki-server binary itself. Will reinstalling this rpm hurt me in
> any way? Without it, I'm not sure how to check my system against the
> messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
  systemctl status  pki-tomcatd@pki-tomcat.service
  journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
  systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
  systemctl | grep dirsrv@


> 
> On 04/28/2016 11:07 AM, Petr Vobornik wrote:
>> On 04/28/2016 04:07 PM, Bret Wortman wrote:
>>> Okay. This morning, I turned back time to 4/1 and started up IPA. It
>>> didn't
>>> work, but I got something new and interesting in the debug log, which
>>> I've
>>> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
>>> pouring out
>>> which doesn't happen when I'm set to real time. Is /this/ significant?
>> Anything in
>>systemctl status  pki-tomcatd@pki-tomcat.service
>> or rather:
>>journalctl -u pki-tomcatd@pki-tomcat.service
>> ?
>>
>> Just to be sure, it might be also worth to check if CA subsystem users
>> have correct certs assigned:
>>   *
>> https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
>>   *
>> https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html
>>
>>>
>>> On 04/27/2016 02:24 PM, Bret Wortman wrote:
 I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
 looks
 logical to me, but I can't spot anything that looks like a root
 cause error.
 The selftests are all okay, I think. The debug log might have
 something, but
 it might also just be complaining about ldap not being up because
 it's not.


 On 04/27/2016 01:11 PM, Rob Crittenden wrote:
> Bret Wortman wrote:
>> So in lieu of fixing these certs, is there an acceptable way to dump
>> them all and start over /without losing the contents of the IPA
>> database/? Or otherwise really screwing ourselves?
> I don't believe there is a way.
>
>> We have a replica that's still up and running and we've switched
>> everyone over to talking to it, but we're at risk with just the one.
> I'd ignore the two unknown certs for now. They look like someone was
> experimenting with issuing a cert and didn't quite get things working.
>
> The CA seems to be throwing an error. I'd check the syslog for
> messages from
> certmonger and look at the CA debug log and selftest log.
>
> rob
>
 [snip]

>>>
>>>
>>
> 


-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-28 Thread Bret Wortman

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't 
have the pki-server binary itself. Will reinstalling this rpm hurt me in 
any way? Without it, I'm not sure how to check my system against the 
messages you provided below.


On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't
work, but I got something new and interesting in the debug log, which I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
   systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
   journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
  * https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
  * https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html



On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It looks
logical to me, but I can't spot anything that looks like a root cause error.
The selftests are all okay, I think. The debug log might have something, but
it might also just be complaining about ldap not being up because it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]








--
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 having cert issues

2016-04-28 Thread Petr Vobornik

On 04/28/2016 04:07 PM, Bret Wortman wrote:
> Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't 
> work, but I got something new and interesting in the debug log, which I've 
> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out 
> which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
  systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
  journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
 * https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
 * https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html

> 
> 
> On 04/27/2016 02:24 PM, Bret Wortman wrote:
>> I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It looks 
>> logical to me, but I can't spot anything that looks like a root cause error. 
>> The selftests are all okay, I think. The debug log might have something, but 
>> it might also just be complaining about ldap not being up because it's not.
>>
>>
>> On 04/27/2016 01:11 PM, Rob Crittenden wrote:
>>> Bret Wortman wrote:
 So in lieu of fixing these certs, is there an acceptable way to dump
 them all and start over /without losing the contents of the IPA
 database/? Or otherwise really screwing ourselves?
>>>
>>> I don't believe there is a way.
>>>
 We have a replica that's still up and running and we've switched
 everyone over to talking to it, but we're at risk with just the one.
>>>
>>> I'd ignore the two unknown certs for now. They look like someone was 
>>> experimenting with issuing a cert and didn't quite get things working.
>>>
>>> The CA seems to be throwing an error. I'd check the syslog for messages 
>>> from 
>>> certmonger and look at the CA debug log and selftest log.
>>>
>>> rob
>>>
>> [snip]
>>
> 
> 
> 


-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-28 Thread Bret Wortman

Okay. This morning, I turned back time to 4/1 and started up IPA. It 
didn't work, but I got something new and interesting in the debug log, 
which I've posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk 
came pouring out which doesn't happen when I'm set to real time. Is 
/this/ significant?



On 04/27/2016 02:24 PM, Bret Wortman wrote:
I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It 
looks logical to me, but I can't spot anything that looks like a root 
cause error. The selftests are all okay, I think. The debug log might 
have something, but it might also just be complaining about ldap not 
being up because it's not.



On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?


I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.


I'd ignore the two unknown certs for now. They look like someone was 
experimenting with issuing a cert and didn't quite get things working.


The CA seems to be throwing an error. I'd check the syslog for 
messages from certmonger and look at the CA debug log and selftest log.


rob


[snip]



-- 
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 having cert issues

2016-04-27 Thread Bret Wortman

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It 
looks logical to me, but I can't spot anything that looks like a root 
cause error. The selftests are all okay, I think. The debug log might 
have something, but it might also just be complaining about ldap not 
being up because it's not.



On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?


I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.


I'd ignore the two unknown certs for now. They look like someone was 
experimenting with issuing a cert and didn't quite get things working.


The CA seems to be throwing an error. I'd check the syslog for 
messages from certmonger and look at the CA debug log and selftest log.


rob


[snip]

--
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 having cert issues

2016-04-27 Thread Rob Crittenden


Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?


I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.


I'd ignore the two unknown certs for now. They look like someone was 
experimenting with issuing a cert and didn't quite get things working.


The CA seems to be throwing an error. I'd check the syslog for messages 
from certmonger and look at the CA debug log and selftest log.


rob



Thanks!


On 04/27/2016 06:05 AM, Bret Wortman wrote:

Was this at all informative?

On 04/26/2016 02:06 PM, Bret Wortman wrote:



On 04/26/2016 01:45 PM, Rob Crittenden wrote:

Bret Wortman wrote:

I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.

I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.

As for the unknowns, the first says status: CA_REJECTED and the error
says "hostname in subject of request 'zw198.private.net' does not
match
principal hostname 'private.net'", with stuck: yes.

The second is similar, but for a different host.


Is it really a different host and why? I think we'd need to see the
full output to know what's going on.



Full output:

Number of certificates and requests being tracked: 10.
Request ID '20140428181940':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PRIVATE-NET/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:51 UTC
principal name: ldap/zsipa.private@private.net
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20140428182016':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:31 UTC
principal name: HTTP/zsipa.private@private.net
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150211141945':
status: CA_REJECTED
ca-error: Server at https://zsipa.private.net/ipa/xml denied our
request, giving up: 2100 (RPC failed at server. Insufficient access:
hostname in subject of request 'zw198.private.net' does not match
principal hostname 'private.net').
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS 
Certificate
DB'
certificate:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194107':
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='424151811070'
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=PRIVATE.NET
subject: CN=CA Audit,O=PRIVATE.NET
expires: 2016-04-17 18:19:19 UTC
key usage: digitalSignature,nonRepudiation
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194108':
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='424151811070'
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=PRIVATE.NET
subject: CN=OCSP Subsystem,O=PRIVATE.NET
expires: 2016-04-17 18:19:18 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command:
post-save command:

Re: [Freeipa-users] IPA server having cert issues

2016-04-27 Thread Bret Wortman


Was this at all informative?

On 04/26/2016 02:06 PM, Bret Wortman wrote:



On 04/26/2016 01:45 PM, Rob Crittenden wrote:

Bret Wortman wrote:

I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.

I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.

As for the unknowns, the first says status: CA_REJECTED and the error
says "hostname in subject of request 'zw198.private.net' does not match
principal hostname 'private.net'", with stuck: yes.

The second is similar, but for a different host.


Is it really a different host and why? I think we'd need to see the 
full output to know what's going on.




Full output:

Number of certificates and requests being tracked: 10.
Request ID '20140428181940':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/dirsrv/slapd-PRIVATE-NET/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS 
Certificate DB'

CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:51 UTC
principal name: ldap/zsipa.private@private.net
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20140428182016':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'

CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:31 UTC
principal name: HTTP/zsipa.private@private.net
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150211141945':
status: CA_REJECTED
ca-error: Server at https://zsipa.private.net/ipa/xml denied our 
request, giving up: 2100 (RPC failed at server. Insufficient access: 
hostname in subject of request 'zw198.private.net' does not match 
principal hostname 'private.net').

stuck: yes
key pair storage: 
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS 
Certificate DB'
certificate: 
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'

CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194107':
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='424151811070'
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=PRIVATE.NET
subject: CN=CA Audit,O=PRIVATE.NET
expires: 2016-04-17 18:19:19 UTC
key usage: digitalSignature,nonRepudiation
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194108':
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='424151811070'
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=PRIVATE.NET
subject: CN=OCSP Subsystem,O=PRIVATE.NET
expires: 2016-04-17 18:19:18 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194109':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS 
Certificate DB',pin='424151811070'
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS 
Certificate DB'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=CA Subsystem,O=PRIVATE.NET
expires: 2016-04-17 18:19:19 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku:

Re: [Freeipa-users] IPA server having cert issues

2016-04-26 Thread Bret Wortman




On 04/26/2016 01:45 PM, Rob Crittenden wrote:

Bret Wortman wrote:

I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.

I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.

As for the unknowns, the first says status: CA_REJECTED and the error
says "hostname in subject of request 'zw198.private.net' does not match
principal hostname 'private.net'", with stuck: yes.

The second is similar, but for a different host.


Is it really a different host and why? I think we'd need to see the 
full output to know what's going on.




Full output:

Number of certificates and requests being tracked: 10.
Request ID '20140428181940':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/dirsrv/slapd-PRIVATE-NET/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-PRIVATE-NET',nickname='Server-Cert',token='NSS 
Certificate DB'

CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:51 UTC
principal name: ldap/zsipa.private@private.net
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20140428182016':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'

CA: IPA
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=zsipa.private.net,O=PRIVATE.NET
expires: 2018-04-02 13:04:31 UTC
principal name: HTTP/zsipa.private@private.net
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150211141945':
status: CA_REJECTED
ca-error: Server at https://zsipa.private.net/ipa/xml denied our 
request, giving up: 2100 (RPC failed at server.  Insufficient access: 
hostname in subject of request 'zw198.private.net' does not match 
principal hostname 'private.net').

stuck: yes
key pair storage: 
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS 
Certificate DB'
certificate: 
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'

CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194107':
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='424151811070'
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=PRIVATE.NET
subject: CN=CA Audit,O=PRIVATE.NET
expires: 2016-04-17 18:19:19 UTC
key usage: digitalSignature,nonRepudiation
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194108':
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='424151811070'
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=PRIVATE.NET
subject: CN=OCSP Subsystem,O=PRIVATE.NET
expires: 2016-04-17 18:19:18 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150816194109':
status: CA_UNREACHABLE
ca-error: Internal error
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB',pin='424151811070'
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS Certificate DB'

CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=PRIVATE.NET
subject: CN=CA Subsystem,O=PRIVATE.NET
expires: 2016-04-17 18:19:19 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:

Re: [Freeipa-users] IPA server having cert issues

2016-04-26 Thread Rob Crittenden


Bret Wortman wrote:

I think I've found a deeper problem, in that I can't update these
because IPA simply won't start at all now.

I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and
2016-04-01 is actually 2036-04-01.

As for the unknowns, the first says status: CA_REJECTED and the error
says "hostname in subject of request 'zw198.private.net' does not match
principal hostname 'private.net'", with stuck: yes.

The second is similar, but for a different host.


Is it really a different host and why? I think we'd need to see the full 
output to know what's going on.


A given host can only get certificates for itself or those delegated to 
it. Hostnames are used for this enforcement so if they don't line up 
you'll see this type of rejection.




No idea what's wrong with the rest, or why nothing will start. Near as I
can tell, Kerberos is failing to start, which is causing everything else
to go toes up.

Early in the startup, in /var/log/messages, there's:

ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (No Kerberos credentials available)


Without more context it's hard to say. 389 is rather chatty about things 
and of course when it starts it has no ticket so it logs a bunch of 
stuff, eventually (hopefully) gets one, and then shuts up.




After that, I get a jar file read pboelm on log4j.jar, then a series of
property setting attempts that don't find matching properties. Then some
cipher errors, then it looks like named starts up okay, and everything
pauses for about 5 minutes before it all comes crashing back down.



I wouldn't get too hung up on particular services just yet. Without 
valid certs things will fail and those problems will cascade. I think we 
just need more details at this point.


rob



Bret

On 04/26/2016 12:40 PM, Petr Vobornik wrote:

On 04/26/2016 06:00 PM, Bret Wortman wrote:

# getcert list | grep expires
  expires: 2018-04-02 13:04:51 UTC
  expires: 2018-04-02 13:04:31 UTC
  expires: unknown
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-17 18:19:18 UTC
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-01 20:16:39 UTC
  expires: 2016-04-17 18:19:35 UTC
  expires: 2016-03-11 13:04:29 UTC
  expires: unknown
#

So some got updated and most didn't. Is there a recommended way to update these
all? The system is still backdated to 3 April (ntpd disabled) at this point.

It's usually good to start renewing(when it doesn't happen automatically
from some reason) with the cert which is about to expired first, i.e.
the one with "2016-03-11 13:04:29"

The process is:
- move date before the cert is about to expired
- leave it up to certmonger or manually force resubmit by `getcert
resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output.

I'm little worried about the fact that CA cert was renewed at date which
is after expiration of the other certs.

Also the `expires: unknown` doesn't look good. Check `getcert list`
output for errors related to the cert.




Bret


On 04/26/2016 11:46 AM, Petr Vobornik wrote:

On 04/26/2016 03:26 PM, Bret Wortman wrote:

On our non-CA IPA server, this is happening, in case it's related and 
illustrative:

# ipa host-del zw113.private.net
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.
#

I would start with checking on all IPA servers if and what certificates
are expired:
# getcert list
or short version to check if there are any:
# getcert list | grep expires

When CA cert is renewed, it is not automatically transfered to clients.
There one must run:
# ipa-certupdate


On 04/26/2016 09:24 AM, Bret Wortman wrote:

I rolled the date on the IPA server in question back to April 1 and ran
"ipa-cacert-manage renew", which said it completed successfully. I rolled the
date back to current and tried restarting ipa using ipactl stop && ipactl
start, but no joy. No more ca renewal errors, but right after the pause I see
this in /var/log/messages:

systemd: kadmin.service: main process exited, code=exited,
status=2/INVALIDARGUMENT
systemd: Unit kadmin.service entered failed state.
systemd: kadmin.service failed.

I rebooted the server just in case, and it's still getting stuck at the same
place. ipa-otpd doesn't get around to starting.


Bret

After the several-minutes-long pause after ipactl start outputs "Starting
pki-tomcatd Service", I get the

On 04/26/2016 08:14 AM, Bret Wortman wrote:

I have an IPA server on a private network which has apparently run into
certificate issues this morning. It's been running without issue for quite a
while, and is on 4.1.4-1 on fedora 21.

This morning, the gui started giving:

IPA Error 907: NetworkError with description "cannot connect to
'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
(SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as expired."

I dug into the logs and after trying

Re: [Freeipa-users] IPA server having cert issues

2016-04-26 Thread Bret Wortman

I should also note that /var/log/dirsrv/slapd-PRIVATE-NET/errors ends 
with a series of "csngen_new_csn - Warning: too much time skew (-2153860 
secs). Current seqnum=1" errors.



On 04/26/2016 12:57 PM, Bret Wortman wrote:
I think I've found a deeper problem, in that I can't update these 
because IPA simply won't start at all now.


I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and 
2016-04-01 is actually 2036-04-01.


As for the unknowns, the first says status: CA_REJECTED and the error 
says "hostname in subject of request 'zw198.private.net' does not 
match principal hostname 'private.net'", with stuck: yes.


The second is similar, but for a different host.

No idea what's wrong with the rest, or why nothing will start. Near as 
I can tell, Kerberos is failing to start, which is causing everything 
else to go toes up.


Early in the startup, in /var/log/messages, there's:

ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may 
provide more information (No Kerberos credentials available)


After that, I get a jar file read pboelm on log4j.jar, then a series 
of property setting attempts that don't find matching properties. Then 
some cipher errors, then it looks like named starts up okay, and 
everything pauses for about 5 minutes before it all comes crashing 
back down.



Bret

On 04/26/2016 12:40 PM, Petr Vobornik wrote:

On 04/26/2016 06:00 PM, Bret Wortman wrote:

# getcert list | grep expires
  expires: 2018-04-02 13:04:51 UTC
  expires: 2018-04-02 13:04:31 UTC
  expires: unknown
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-17 18:19:18 UTC
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-01 20:16:39 UTC
  expires: 2016-04-17 18:19:35 UTC
  expires: 2016-03-11 13:04:29 UTC
  expires: unknown
#

So some got updated and most didn't. Is there a recommended way to update these
all? The system is still backdated to 3 April (ntpd disabled) at this point.

It's usually good to start renewing(when it doesn't happen automatically
from some reason) with the cert which is about to expired first, i.e.
the one with "2016-03-11 13:04:29"

The process is:
- move date before the cert is about to expired
- leave it up to certmonger or manually force resubmit by `getcert
resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output.

I'm little worried about the fact that CA cert was renewed at date which
is after expiration of the other certs.

Also the `expires: unknown` doesn't look good. Check `getcert list`
output for errors related to the cert.



Bret


On 04/26/2016 11:46 AM, Petr Vobornik wrote:

On 04/26/2016 03:26 PM, Bret Wortman wrote:

On our non-CA IPA server, this is happening, in case it's related and 
illustrative:

# ipa host-del zw113.private.net
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.
#

I would start with checking on all IPA servers if and what certificates
are expired:
# getcert list
or short version to check if there are any:
# getcert list | grep expires

When CA cert is renewed, it is not automatically transfered to clients.
There one must run:
# ipa-certupdate


On 04/26/2016 09:24 AM, Bret Wortman wrote:

I rolled the date on the IPA server in question back to April 1 and ran
"ipa-cacert-manage renew", which said it completed successfully. I rolled the
date back to current and tried restarting ipa using ipactl stop && ipactl
start, but no joy. No more ca renewal errors, but right after the pause I see
this in /var/log/messages:

systemd: kadmin.service: main process exited, code=exited,
status=2/INVALIDARGUMENT
systemd: Unit kadmin.service entered failed state.
systemd: kadmin.service failed.

I rebooted the server just in case, and it's still getting stuck at the same
place. ipa-otpd doesn't get around to starting.


Bret

After the several-minutes-long pause after ipactl start outputs "Starting
pki-tomcatd Service", I get the

On 04/26/2016 08:14 AM, Bret Wortman wrote:

I have an IPA server on a private network which has apparently run into
certificate issues this morning. It's been running without issue for quite a
while, and is on 4.1.4-1 on fedora 21.

This morning, the gui started giving:

IPA Error 907: NetworkError with description "cannot connect to
'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
(SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as expired."

I dug into the logs and after trying to restart ipa using ipactl, there was a
length pause, then:

dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in
database "/etc/httpd/alias" is no longer valid.
dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS
Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer valid.

Re: [Freeipa-users] IPA server having cert issues

2016-04-26 Thread Bret Wortman

I think I've found a deeper problem, in that I can't update these 
because IPA simply won't start at all now.


I mistyped one of these -- the 2016-03-11 is actually 2018-03-11, and 
2016-04-01 is actually 2036-04-01.


As for the unknowns, the first says status: CA_REJECTED and the error 
says "hostname in subject of request 'zw198.private.net' does not match 
principal hostname 'private.net'", with stuck: yes.


The second is similar, but for a different host.

No idea what's wrong with the rest, or why nothing will start. Near as I 
can tell, Kerberos is failing to start, which is causing everything else 
to go toes up.


Early in the startup, in /var/log/messages, there's:

ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide 
more information (No Kerberos credentials available)


After that, I get a jar file read pboelm on log4j.jar, then a series of 
property setting attempts that don't find matching properties. Then some 
cipher errors, then it looks like named starts up okay, and everything 
pauses for about 5 minutes before it all comes crashing back down.



Bret

On 04/26/2016 12:40 PM, Petr Vobornik wrote:

On 04/26/2016 06:00 PM, Bret Wortman wrote:

# getcert list | grep expires
  expires: 2018-04-02 13:04:51 UTC
  expires: 2018-04-02 13:04:31 UTC
  expires: unknown
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-17 18:19:18 UTC
  expires: 2016-04-17 18:19:19 UTC
  expires: 2016-04-01 20:16:39 UTC
  expires: 2016-04-17 18:19:35 UTC
  expires: 2016-03-11 13:04:29 UTC
  expires: unknown
#

So some got updated and most didn't. Is there a recommended way to update these
all? The system is still backdated to 3 April (ntpd disabled) at this point.

It's usually good to start renewing(when it doesn't happen automatically
from some reason) with the cert which is about to expired first, i.e.
the one with "2016-03-11 13:04:29"

The process is:
- move date before the cert is about to expired
- leave it up to certmonger or manually force resubmit by `getcert
resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output.

I'm little worried about the fact that CA cert was renewed at date which
is after expiration of the other certs.

Also the `expires: unknown` doesn't look good. Check `getcert list`
output for errors related to the cert.




Bret


On 04/26/2016 11:46 AM, Petr Vobornik wrote:

On 04/26/2016 03:26 PM, Bret Wortman wrote:

On our non-CA IPA server, this is happening, in case it's related and 
illustrative:

# ipa host-del zw113.private.net
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.
#

I would start with checking on all IPA servers if and what certificates
are expired:
# getcert list
or short version to check if there are any:
# getcert list | grep expires

When CA cert is renewed, it is not automatically transfered to clients.
There one must run:
# ipa-certupdate


On 04/26/2016 09:24 AM, Bret Wortman wrote:

I rolled the date on the IPA server in question back to April 1 and ran
"ipa-cacert-manage renew", which said it completed successfully. I rolled the
date back to current and tried restarting ipa using ipactl stop && ipactl
start, but no joy. No more ca renewal errors, but right after the pause I see
this in /var/log/messages:

systemd: kadmin.service: main process exited, code=exited,
status=2/INVALIDARGUMENT
systemd: Unit kadmin.service entered failed state.
systemd: kadmin.service failed.

I rebooted the server just in case, and it's still getting stuck at the same
place. ipa-otpd doesn't get around to starting.


Bret

After the several-minutes-long pause after ipactl start outputs "Starting
pki-tomcatd Service", I get the

On 04/26/2016 08:14 AM, Bret Wortman wrote:

I have an IPA server on a private network which has apparently run into
certificate issues this morning. It's been running without issue for quite a
while, and is on 4.1.4-1 on fedora 21.

This morning, the gui started giving:

IPA Error 907: NetworkError with description "cannot connect to
'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
(SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as expired."

I dug into the logs and after trying to restart ipa using ipactl, there was a
length pause, then:

dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in
database "/etc/httpd/alias" is no longer valid.
dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS
Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer valid.
dogtag-ipa-ca-renew-agent-submit: Updated certificate not available.
named-pkcs11[3437]: client 192.168.208.205#57832: update
'208.168.192.in-addr.arpa/IN' denied

and then things start shutting down. I can't start ipa at all

Re: [Freeipa-users] IPA server having cert issues

2016-04-26 Thread Petr Vobornik

On 04/26/2016 06:00 PM, Bret Wortman wrote:
> # getcert list | grep expires
>  expires: 2018-04-02 13:04:51 UTC
>  expires: 2018-04-02 13:04:31 UTC
>  expires: unknown
>  expires: 2016-04-17 18:19:19 UTC
>  expires: 2016-04-17 18:19:18 UTC
>  expires: 2016-04-17 18:19:19 UTC
>  expires: 2016-04-01 20:16:39 UTC
>  expires: 2016-04-17 18:19:35 UTC
>  expires: 2016-03-11 13:04:29 UTC
>  expires: unknown
> #
> 
> So some got updated and most didn't. Is there a recommended way to update 
> these 
> all? The system is still backdated to 3 April (ntpd disabled) at this point.

It's usually good to start renewing(when it doesn't happen automatically
from some reason) with the cert which is about to expired first, i.e.
the one with "2016-03-11 13:04:29"

The process is:
- move date before the cert is about to expired
- leave it up to certmonger or manually force resubmit by `getcert
resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output.

I'm little worried about the fact that CA cert was renewed at date which
is after expiration of the other certs.

Also the `expires: unknown` doesn't look good. Check `getcert list`
output for errors related to the cert.


> 
> 
> Bret
> 
> 
> On 04/26/2016 11:46 AM, Petr Vobornik wrote:
>> On 04/26/2016 03:26 PM, Bret Wortman wrote:
>>> On our non-CA IPA server, this is happening, in case it's related and 
>>> illustrative:
>>>
>>> # ipa host-del zw113.private.net
>>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
>>> certificate/key database is in an old, unsupported format.
>>> #
>> I would start with checking on all IPA servers if and what certificates
>> are expired:
>># getcert list
>> or short version to check if there are any:
>># getcert list | grep expires
>>
>> When CA cert is renewed, it is not automatically transfered to clients.
>> There one must run:
>># ipa-certupdate
>>
>>> On 04/26/2016 09:24 AM, Bret Wortman wrote:
 I rolled the date on the IPA server in question back to April 1 and ran
 "ipa-cacert-manage renew", which said it completed successfully. I rolled 
 the
 date back to current and tried restarting ipa using ipactl stop && ipactl
 start, but no joy. No more ca renewal errors, but right after the pause I 
 see
 this in /var/log/messages:

 systemd: kadmin.service: main process exited, code=exited,
 status=2/INVALIDARGUMENT
 systemd: Unit kadmin.service entered failed state.
 systemd: kadmin.service failed.

 I rebooted the server just in case, and it's still getting stuck at the 
 same
 place. ipa-otpd doesn't get around to starting.


 Bret

 After the several-minutes-long pause after ipactl start outputs "Starting
 pki-tomcatd Service", I get the

 On 04/26/2016 08:14 AM, Bret Wortman wrote:
> I have an IPA server on a private network which has apparently run into
> certificate issues this morning. It's been running without issue for 
> quite a
> while, and is on 4.1.4-1 on fedora 21.
>
> This morning, the gui started giving:
>
> IPA Error 907: NetworkError with description "cannot connect to
> 'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
> (SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as 
> expired."
>
> I dug into the logs and after trying to restart ipa using ipactl, there 
> was a
> length pause, then:
>
> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
> certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in
> database "/etc/httpd/alias" is no longer valid.
> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
> certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS
> Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer 
> valid.
> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available.
> named-pkcs11[3437]: client 192.168.208.205#57832: update
> '208.168.192.in-addr.arpa/IN' denied
>
> and then things start shutting down. I can't start ipa at all using 
> ipactl.
>
> So at present, our DNS is down. Authentication should work for a while, 
> but
> I'd like to get this working again as quickly as possible. Any ideas? I 
> deal
> with certificates so infrequently (like only when something like this
> happens) that I'm not sure where to start.
>
> Thanks!
>
>
> -- 
> *Bret Wortman*
> /Coming soon to Kickstarter.../
> 
> http://wrapbuddies.co/
>
> 


-- 
Petr Vobornik

-- 
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 having cert issues

2016-04-26 Thread Bret Wortman


# getcert list | grep expires
expires: 2018-04-02 13:04:51 UTC
expires: 2018-04-02 13:04:31 UTC
expires: unknown
expires: 2016-04-17 18:19:19 UTC
expires: 2016-04-17 18:19:18 UTC
expires: 2016-04-17 18:19:19 UTC
expires: 2016-04-01 20:16:39 UTC
expires: 2016-04-17 18:19:35 UTC
expires: 2016-03-11 13:04:29 UTC
expires: unknown
#

So some got updated and most didn't. Is there a recommended way to 
update these all? The system is still backdated to 3 April (ntpd 
disabled) at this point.



Bret


On 04/26/2016 11:46 AM, Petr Vobornik wrote:

On 04/26/2016 03:26 PM, Bret Wortman wrote:

On our non-CA IPA server, this is happening, in case it's related and 
illustrative:

# ipa host-del zw113.private.net
ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The
certificate/key database is in an old, unsupported format.
#

I would start with checking on all IPA servers if and what certificates
are expired:
   # getcert list
or short version to check if there are any:
   # getcert list | grep expires

When CA cert is renewed, it is not automatically transfered to clients.
There one must run:
   # ipa-certupdate


On 04/26/2016 09:24 AM, Bret Wortman wrote:

I rolled the date on the IPA server in question back to April 1 and ran
"ipa-cacert-manage renew", which said it completed successfully. I rolled the
date back to current and tried restarting ipa using ipactl stop && ipactl
start, but no joy. No more ca renewal errors, but right after the pause I see
this in /var/log/messages:

systemd: kadmin.service: main process exited, code=exited,
status=2/INVALIDARGUMENT
systemd: Unit kadmin.service entered failed state.
systemd: kadmin.service failed.

I rebooted the server just in case, and it's still getting stuck at the same
place. ipa-otpd doesn't get around to starting.


Bret

After the several-minutes-long pause after ipactl start outputs "Starting
pki-tomcatd Service", I get the

On 04/26/2016 08:14 AM, Bret Wortman wrote:

I have an IPA server on a private network which has apparently run into
certificate issues this morning. It's been running without issue for quite a
while, and is on 4.1.4-1 on fedora 21.

This morning, the gui started giving:

IPA Error 907: NetworkError with description "cannot connect to
'https://zsipa.private.net:443/ca/agent/ca/displayBySerial':
(SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as expired."

I dug into the logs and after trying to restart ipa using ipactl, there was a
length pause, then:

dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in
database "/etc/httpd/alias" is no longer valid.
dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS
Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer valid.
dogtag-ipa-ca-renew-agent-submit: Updated certificate not available.
named-pkcs11[3437]: client 192.168.208.205#57832: update
'208.168.192.in-addr.arpa/IN' denied

and then things start shutting down. I can't start ipa at all using ipactl.

So at present, our DNS is down. Authentication should work for a while, but
I'd like to get this working again as quickly as possible. Any ideas? I deal
with certificates so infrequently (like only when something like this
happens) that I'm not sure where to start.

Thanks!


--
*Bret Wortman*
/Coming soon to Kickstarter.../

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] IPA server having cert issues

2016-04-26 Thread Petr Vobornik

On 04/26/2016 03:26 PM, Bret Wortman wrote:
> On our non-CA IPA server, this is happening, in case it's related and 
> illustrative:
> 
> # ipa host-del zw113.private.net
> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The 
> certificate/key database is in an old, unsupported format.
> #

I would start with checking on all IPA servers if and what certificates
are expired:
  # getcert list
or short version to check if there are any:
  # getcert list | grep expires

When CA cert is renewed, it is not automatically transfered to clients.
There one must run:
  # ipa-certupdate

> 
> On 04/26/2016 09:24 AM, Bret Wortman wrote:
>> I rolled the date on the IPA server in question back to April 1 and ran 
>> "ipa-cacert-manage renew", which said it completed successfully. I rolled 
>> the 
>> date back to current and tried restarting ipa using ipactl stop && ipactl 
>> start, but no joy. No more ca renewal errors, but right after the pause I 
>> see 
>> this in /var/log/messages:
>>
>> systemd: kadmin.service: main process exited, code=exited, 
>> status=2/INVALIDARGUMENT
>> systemd: Unit kadmin.service entered failed state.
>> systemd: kadmin.service failed.
>>
>> I rebooted the server just in case, and it's still getting stuck at the same 
>> place. ipa-otpd doesn't get around to starting.
>>
>>
>> Bret
>>
>> After the several-minutes-long pause after ipactl start outputs "Starting 
>> pki-tomcatd Service", I get the
>>
>> On 04/26/2016 08:14 AM, Bret Wortman wrote:
>>> I have an IPA server on a private network which has apparently run into 
>>> certificate issues this morning. It's been running without issue for quite 
>>> a 
>>> while, and is on 4.1.4-1 on fedora 21.
>>>
>>> This morning, the gui started giving:
>>>
>>> IPA Error 907: NetworkError with description "cannot connect to 
>>> 'https://zsipa.private.net:443/ca/agent/ca/displayBySerial': 
>>> (SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as 
>>> expired."
>>>
>>> I dug into the logs and after trying to restart ipa using ipactl, there was 
>>> a 
>>> length pause, then:
>>>
>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
>>> certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in 
>>> database "/etc/httpd/alias" is no longer valid.
>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available
>>> certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS 
>>> Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer valid.
>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available.
>>> named-pkcs11[3437]: client 192.168.208.205#57832: update 
>>> '208.168.192.in-addr.arpa/IN' denied
>>>
>>> and then things start shutting down. I can't start ipa at all using ipactl.
>>>
>>> So at present, our DNS is down. Authentication should work for a while, but 
>>> I'd like to get this working again as quickly as possible. Any ideas? I 
>>> deal 
>>> with certificates so infrequently (like only when something like this 
>>> happens) that I'm not sure where to start.
>>>
>>> Thanks!
>>>
>>>
>>> -- 
>>> *Bret Wortman*
>>> /Coming soon to Kickstarter.../
>>> 
>>> http://wrapbuddies.co/
>>>
-- 
Petr Vobornik

-- 
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 having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

Re: [Freeipa-users] IPA server having cert issues

33 matches

Site Navigation

Mail list logo

Footer information