On 28.6.2014 00:19, Rob Crittenden wrote:
I'm going to consolidate all reviews for 241 - 303 here. I'm not doing
this in any particular order.
OK, I will send further patches only in this thread.
--------
Missing man page for ipa-certupdate
I did not want to delay the patch, so I have sent it without man page.
Will fix.
--------
Not a very nice error from ipa-cacert-manage install when loading a bad
cert:
# ipa-cacert-manage install /etc/group
Installing CA certificate, please wait
(SEC_ERROR_INVALID_ARGS) security library: invalid arguments.
Right. Fixed.
The ipa-cacert-manage makes no mention of changing the cert chaining. It
just adds the options, not what they do. Here is what happened when I
tried it:
# ipa-cacert-manage renew --external-ca
Exporting CA certificate signing request, please wait
The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run
ipa-cacert-manage as:
ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate
--external-ca-file=/path/to/external_ca_certificate
The ipa-cacert-manage command was successful
[ go off and sign it ]
# ipa-cacert-manage renew --external-cert-file=/home/rcrit/ca_db/ipa.crt
--external-ca-file=/home/rcrit/ca_db/ca.crt
Importing the renewed CA certificate, please wait
Resubmitting certmonger request '20140627134654' timed out, please check
the request manually
The request was actually in MONITORING, so ok.
But the CA is now not working
# ipa cert-request --principal test/`hostname` csr
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)
# ipa cert-show 1
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)
The CA database doesn't have my external CA
# certutil -Ld /etc/pki/pki-tomcat/alias/
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca CTu,Cu,Cu
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
Not sure if this is related:
# pki cert-find
PKIException: Internal Server Error
The problem is not in the missing external CA cert (the CA always worked
fine without it for me, so I never bothered adding it). The problem is
that Dogtag can't connect to DS, because it does not like its server
certificate. Which is weird, because when I try doing the same using
ldapsearch everything seems to work fine:
# LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://$HOSTNAME
-Y EXTERNAL -b o=ipaca -s base
Please enter pin, password, or pass phrase for security token
'ldap(0)':
SASL/EXTERNAL authentication started
SASL username: cn=CA Subsystem,o=EXAMPLE.COM
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <o=ipaca> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
# ipaca
dn: o=ipaca
objectClass: top
objectClass: organization
o: ipaca
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
Adding the old CA cert back to /etc/pki/pki-tomcat/alias does not fix
this, although the error is different (ipa cert-show fails with internal
error caused by "XMLSyntaxError: None", pki cert-find fails with
"PKIException: Error searching certs in CertService.searchCerts!").
Adding the external CA cert does not fix this either.
I'm pretty sure chaining change from self-signed to signed by external
CA worked for me the last time I have tested it, but it has been some
time. Maybe something changed in Dogtag? I don't know. Any ideas?
--------
Note that I tried again with a fresh external install, this time without
the --external-ca flag and it basically went through the same steps but
this time it was successful.
Good.
--------
I did a re-install and tried a renewal (with just ipa-server-install). I
moved time forward and saw this:
Request ID '20140627150913':
status: MONITORING
ca-error: Server at
"https://sif.greyoak.com:8443/ca/agent/ca/profileProcess"; replied: 1:
Invalid Credential.
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='323234924210'
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=GREYOAK.COM
subject: CN=CA Audit,O=GREYOAK.COM
expires: 2016-06-16 15:08:34 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
How it is monitoring with a ca-error I don't know.
I forced a resubmit and it renewed ok. Chances are certmonger would have
taken care of this automatically.
I leaped forward 2 more times and had to restart certmonger a few times
to kick things but again, it did eventually renew as expected.
So that looks ok and covers much of the first patch set.
OK, thanks.
---------------
ipa-client-install still fails for me in RHEL-5 with an external CA:
2014-06-27 14:04:31,202 DEBUG trying to retrieve CA cert via LDAP from
ldap://sif.greyoak.com
2014-06-27 14:04:32,312 INFO Successfully retrieved CA cert
Subject: /O=GREYOAK.COM/CN=Certificate Authority
Issuer: /CN=External Authority
2014-06-27 14:04:32,467 DEBUG args=/usr/sbin/ipa-join -s sif.greyoak.com
-b dc=greyoak,dc=com
2014-06-27 14:04:32,467 DEBUG stdout=
2014-06-27 14:04:32,467 DEBUG stderr=libcurl failed to execute the HTTP
POST transaction. SSL certificate problem, verify that the CA cert is
OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
This is the query that is being done:
[27/Jun/2014:14:04:31 -0400] conn=18 op=3 SRCH
base="CN=CAcert,CN=ipa,CN=etc,dc=greyoak,dc=com" scope=0
filter="(objectClass=pkiCA)" attrs="cacertificate;binary"
It returns a single object, the dogtag-issued CA certificate, not the
entire chain, hence the failure.
I doubt this ever worked, as there can be only one certificate in
cn=CAcert. Can't do much about this, unless you want to fix it in RHEL 5.
Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while
/usr/share/ipa/html/ca.crt contains the full chain.
Right, will fix.
This works:
# wget -O /tmp/ca.crt http://sif.greyoak.com/ipa/config/ca.crt
# ipa-client-install --server=sif.greyoak.com --domain=greyoak.com -p
admin -w password -U --ca-cert-file=/tmp/ca.crt
--------
Enrollment on RHEL-6 also puts a single CA in /etc/ipa/ca.crt but
enrollment succeeds.
That's expected, it also uses cn=CAcert. Any idea why it works on RHEL 6
but not on RHEL 5?
Enrollment on F-20 puts all certs into /etc/ipa/ca.crt. My last test was
re-freshing the CA cert from an external and I confirmed that both the
IPA CA certs are in /etc/ipa/ca.crt and in LDAP.
--------
Ok, so I took my working, renewed Externally-issued CA install and
generated a PKCS#12 for another host. Using that I did a CA-less install.
I tried ipa-ca-install on that and it failed. The log is attached,
though it shouldn't be called ipareplica-ca-install.log in this case.
There are conflicting certificates with the same nickname in the PKCS#12
file and the certificate store, which causes the error. Will fix.
--------
Installing a replica and adding a CA to it using ipa-replica-ca-install
worked fine.
--------
I renewed the CA once again using ipa-cacert-manage then used
ipa-certupdate to apply the result successfully on the replica except
for the CA itself. It is still has the serial number it was installed
with and not the updated value in caSigningCert cert-pki-ca.
Right, fixed.
--------
Patch 293
Just curious, but what is the advantage of writing out the certificates
in pk11-kit format when you can drop the cert(s) and call
update-ca-trust? Is it a control thing, particularly for the
trusted/untrusted?
Yes, I can add the out-of-band trust policy as well as nicknames to the
certificates this way. Also, it is easier to manage one file rather than
a bunch of them.
Patch 294
I think the git commit should include the bit about using the CA file
from the replica config as well.
OK.
Patch 303.
Is the context as cli_installer a cut-n-paste or a conscious choice?
It is indeed copy-paste. Is it wrong?
Should there be some logging in here? What happens if the kinit fails,
or something else goes bump? There is no debug/verbose output option to
see what is going on.
This is all handled by admintool, including an option for verbose output
(-v).
In update_client() should it be paranoid enough to have a try/except
around the reads and writes?
Sure, why not.
I'm assuming that the certutil call in update_db() is because the other
cert management we have is in ipaserver, right? Perhaps certs.py needs
to be moved to ipapython (and maybe renamed)? A patch for another day if
you agree and please file a ticket.
I agree: <https://fedorahosted.org/freeipa/ticket/4416>.
I still need to do more chain-updating and upgrade testing.
rob
On 30.6.2014 19:36, Rob Crittenden wrote:
A few more things after more testing.
If one renews an externally-issued CA then you can end up with multiple
certs for the IPA CA in /etc/pki/nssdb (for each issued cert). These do
not seem to be cleaned up on uninstall.
Right, you need to call "certutil -D" multiple times if there are
multiple certs with the same nick. Fixed.
On upgrade from 3.3.5 seeing:
Unexpected error - see /var/log/ipaupgrade.log for details:
InvalidSyntax: object class ipaCertificate: Unknown required attribute
type "ipaPublicKey": Invalid syntax.
/var/log/ipaupgrade ends with:
2014-06-30T15:03:11Z DEBUG wait_for_open_ports: localhost [389] timeout 300
2014-06-30T15:08:12Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 640, in run_script
return_value = main_function()
File "/usr/sbin/ipa-upgradeconfig", line 1171, in main
ds.start(ds_serverid)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 297, in start
self.service.start(instance_name, capture_output=capture_output,
wait=wait)
File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
line 262, in start
self.wait_for_open_ports(self.service_instance(instance_name))
File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
line 228, in wait_for_open_ports
self.api.env.startup_timeout)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
1153, in wait_for_open_ports
raise socket.timeout()
2014-06-30T15:08:12Z DEBUG The ipa-upgradeconfig command failed,
exception: timeout:
Turns out it blew up so badly that it didn't restore dse.ldif when the
upgrade finished, something I thought was impossible. This is a pretty
serious problem in itself (and likely unrelated to these patches).
This might be related to the fact that I accidentally left an unresolved
merge conflict in 60basev3.ldif. Fixed.
rob
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
