Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Jan Cholasta wrote: On 12.6.2014 09:49, Jan Cholasta wrote: On 20.5.2014 21:38, Rob Crittenden wrote: Jan Cholasta wrote: On 25.4.2014 10:51, Jan Cholasta wrote: On 24.4.2014 23:16, Rob Crittenden wrote: Jan Cholasta wrote: On 10.4.2014 22:06, Rob Crittenden wrote: Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: On 7.4.2014 20:09, Rob Crittenden wrote: Rob Crittenden wrote: 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a waiting message, at least for debugging. Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. Are you sure you have 247.1 (now 247.2)? I can see at http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html that I have sent the correct version of the patches. The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us. Well, I can add --certmonger-timeout option to ipa-cacert-manage, if that's what you want. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. Added some messages about what's going on. I dpn't see an update to 251 either. Please make sure you have 251.1 (now 251.2). There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA. This stuff takes time :-) What would you like to see in the output, that's not already there? I think the ipa-cacert-manage man page is missing one really important piece: why would you ever need to run this? And when? Added a paragraph about this. It's better, couple of comments: Add the in between renew and CA in used to manually renew CA certificate of and When IPA CA OK. I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this? [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File lxml.etree.pyx, line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File parser.pxi, line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Jan Cholasta wrote: On 25.4.2014 10:51, Jan Cholasta wrote: On 24.4.2014 23:16, Rob Crittenden wrote: Jan Cholasta wrote: On 10.4.2014 22:06, Rob Crittenden wrote: Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: On 7.4.2014 20:09, Rob Crittenden wrote: Rob Crittenden wrote: 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a waiting message, at least for debugging. Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. Are you sure you have 247.1 (now 247.2)? I can see at http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html that I have sent the correct version of the patches. The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us. Well, I can add --certmonger-timeout option to ipa-cacert-manage, if that's what you want. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. Added some messages about what's going on. I dpn't see an update to 251 either. Please make sure you have 251.1 (now 251.2). There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA. This stuff takes time :-) What would you like to see in the output, that's not already there? I think the ipa-cacert-manage man page is missing one really important piece: why would you ever need to run this? And when? Added a paragraph about this. It's better, couple of comments: Add the in between renew and CA in used to manually renew CA certificate of and When IPA CA OK. I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this? [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File lxml.etree.pyx, line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File parser.pxi, line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File parser.pxi, line 1673, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:101322)
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
On 04/24/2014 11:16 PM, Rob Crittenden wrote:
Jan Cholasta wrote:
On 10.4.2014 22:06, Rob Crittenden wrote:
Some in-line, a whole ton of data appended to end.
Jan Cholasta wrote:
On 7.4.2014 20:09, Rob Crittenden wrote:
Rob Crittenden wrote:
[...]
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line
168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py,
line
189, in validate_options
raise ScriptError('Must be root to run %s' %
self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be
root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
That's correct, you can run it only as root, because you can't resubmit
certmonger requests as a regular user.
Yes but one shouldn't get a traceback!
You get the traceback only in verbose mode. I did not invent this, it's
how ipapython.admintool does things.
Ok, I'll blame Petr.
In verbose mode you get all the debugging information that's written to
logs, and that includes the tracebacks. I stand by this decision.
If the command is normally so quiet that you need the -v flag for normal
operation, that's a problem. Log interesting messages at INFO.
http://www.freeipa.org/page/V3/Logging_and_output#Design
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
On 24.4.2014 23:16, Rob Crittenden wrote: Jan Cholasta wrote: On 10.4.2014 22:06, Rob Crittenden wrote: Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: On 7.4.2014 20:09, Rob Crittenden wrote: Rob Crittenden wrote: 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a waiting message, at least for debugging. Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. Are you sure you have 247.1 (now 247.2)? I can see at http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html that I have sent the correct version of the patches. The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us. Well, I can add --certmonger-timeout option to ipa-cacert-manage, if that's what you want. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. Added some messages about what's going on. I dpn't see an update to 251 either. Please make sure you have 251.1 (now 251.2). There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA. This stuff takes time :-) What would you like to see in the output, that's not already there? I think the ipa-cacert-manage man page is missing one really important piece: why would you ever need to run this? And when? Added a paragraph about this. It's better, couple of comments: Add the in between renew and CA in used to manually renew CA certificate of and When IPA CA OK. I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this? [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py, line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File lxml.etree.pyx, line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File parser.pxi, line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File parser.pxi, line 1673, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:101322) [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File parser.pxi, line 1074, in lxml.etree._BaseParser._parseDoc
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Jan Cholasta wrote:
On 10.4.2014 22:06, Rob Crittenden wrote:
Some in-line, a whole ton of data appended to end.
Jan Cholasta wrote:
On 7.4.2014 20:09, Rob Crittenden wrote:
Rob Crittenden wrote:
242
I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) =
handler(...)
rather than examining result[0], etc. That may be beyond the scope of
this patch though.
Yes. It would be nice if certmonger included a Python module for helper
scripts...
Yes, but what I mean is the internal handling returns tuples of data
with unique variable names, then plucks them out positionally.
len(result) depends on result[0], so you can't do result, message =
handler(...), because it would blow up when len(result) != 2.
OK.
243
You are going to end up with a lot of acis with the same comment
value.
Perhaps add the host in there as well.
These are not removed when a master is deleted.
I merely did the same thing as the Add CA Certificates for renewals
and Modify CA Certificates for renewals ACIs.
I agree it's suboptimal, but IMO it should be fixed in the scope of
https://fedorahosted.org/freeipa/ticket/3416 (the ipa masters
hostgroup part).
There is a replica_cleanup() method in replication.py. I don't know why
this couldn't be added there.
OK, added, see patch 263. But we should do the hostgroup thing anyway,
this solution sucks.
I completely agree.
247
We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it
might
be worth spitting out a waiting message, at least for debugging.
Added a timeout argument.
Did you forget to send this one, I didn't see an update to 247.
Are you sure you have 247.1 (now 247.2)?
I can see at
http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html
that I have sent the correct version of the patches.
The call has a timeout, the callers don't use it. I guess it'll do for
now, but these almost always come back to bite us.
251
The tool should provide some feedback while it's running. For the
impatient (me) it takes a really long time and it's hard to know
what is
going on, something in between nothing and full debug output.
Added some messages about what's going on.
I dpn't see an update to 251 either.
Please make sure you have 251.1 (now 251.2).
There is a little bit more output but there are still very long periods
of waiting between any visual activity, particularly when doing it on an
IPA self-signed CA.
The man page needs some more work too. I think some more
explanation is
needed and an example would probably be really helpful as well. I
think
particularly an example for external certs and a description of what
you
mean by Self-signed CA (I assume you mean IPA-provided). I don't think
it really matters how many steps there are unless you are going to
provide progress output.
Reworded the man page a little bit.
Got a backtrace when running as non-root:
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line
168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py,
line
189, in validate_options
raise ScriptError('Must be root to run %s' %
self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
That's correct, you can run it only as root, because you can't resubmit
certmonger requests as a regular user.
Yes but one shouldn't get a traceback!
You get the traceback only in verbose mode. I did not invent this, it's
how ipapython.admintool does things.
Ok, I'll blame Petr.
After moving time forward on the replica these certificates are in
CA_WORKING:
ipaCert
auditSigningCert cert-pki-ca
ocspSigningCert cert-pki-ca
subsystemCert cert-pki-ca
cn=ca_renewal is completely empty on the replica. On the master it only
has the subsystemCert. I'm guessing this is at least partly due to my
switching time one system at a time rather than (somewhat)
simultaneously, but it still would have blown up with 3 missing certs.
Can you post the related log messages from /var/log/messages from the
master somewhere?
There's not much I can do about broken replication. I think you hit
https://fedorahosted.org/389/ticket/47632.
rob
Thanks for the review.
Updated and rebased patches attached.
Patch 262 has lots of lint errors because you're adding arguments to
functions that don't currently define one,
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: On 7.4.2014 20:09, Rob Crittenden wrote: Rob Crittenden wrote: Jan Cholasta wrote: Hi, the attached patches implement automatic CA certificate renewal as well as the initial version of the CA certificate management tool. Requires my patches 172-196. In order to test, you must install current git version of certmonger (see https://fedorahosted.org/certmonger/ticket/26) and set SELinux to permissive (see https://bugzilla.redhat.com/show_bug.cgi?id=1078783). Make sure you install certmonger before running ipa-server-install/ipa-replica-install. On F20 you can use RPMs located at http://jcholast.fedorapeople.org/certmonger-git/. To test automatic renewal, move system time forward (see https://fedorahosted.org/freeipa/ticket/2803#comment:17 for more info about certificate renewal testing, nickname of the CA certificate is caSigningCert cert-pki-ca). In CA-full installs the renewal should be fully automatic, in CA-less installs you should be alerted via syslog to renew the certificate using ipa-cacert-manage. To test manual renewal, run ipa-cacert-manage renew. You can run it on any CA master. To make the renewed certificate available on other CA masters, you must run getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca' on each of them. Note that currently you can't change the chaining of the CA certificate. 241 Not to be too anal, but would it be too outlandish to compare the Authority Key Identifier (if there is one) with the Subject Key ID to see if the cert is self-signed? Same subject then yeah, it is probably self-signed. The keys match? Definitely. Authority key identifier is not mandatory, so it's not good enough. You could verify the certificate's signature with its public key, but I haven't figured out how to do that in python-nss. Also, if someone uses the subject name of the issuer for their CA certificate, I think they will run into all kinds of problems anyway. Ok. 242 I wonder if it would be clearer to use variables instead of a raw list in the return value for these handlers: (result, message) = handler(...) rather than examining result[0], etc. That may be beyond the scope of this patch though. Yes. It would be nice if certmonger included a Python module for helper scripts... Yes, but what I mean is the internal handling returns tuples of data with unique variable names, then plucks them out positionally. x509.normalize_certificate() can raise an exception, there should be a try/except around it. If there is an exception, it will be caught in the try/except block at the end of the script. Well, ok. For an invalid cookie, please include the values seen in the environment in the error message. Added. 243 You are going to end up with a lot of acis with the same comment value. Perhaps add the host in there as well. These are not removed when a master is deleted. I merely did the same thing as the Add CA Certificates for renewals and Modify CA Certificates for renewals ACIs. I agree it's suboptimal, but IMO it should be fixed in the scope of https://fedorahosted.org/freeipa/ticket/3416 (the ipa masters hostgroup part). There is a replica_cleanup() method in replication.py. I don't know why this couldn't be added there. 244 There are now several different places where the caCertificate value is updated. I wonder if it's time for a function. I found it it in dsinstance.py, upload_cacert and now renew_ca_cert. I have a patch for that, but I haven't posted it yet, since there are some other changes in it as well. Ok. 246 caRenewalMaster should be checked when a replica is deleted and moved to another master. This is a good idea. I wonder if a ticket should be opened to do something similar for CRL generation. Add new patch 262 for this. +1 on doing the same for CRL generation. 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a waiting message, at least for debugging. Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. I had logging in the code before, but I removed it when I moved the code to ipapython.certmonger. Silly me. Fixed. 249 nss_init() is always scary to me since we can only have one. I didn't see anything blow up, just wondering if this should be wrapped with an is_initialized()-shutdown() at the top. Fixed (also for verify_server_cert_validity). Ok. The find_cert_from_nickname() should be in a try/except in case the cert is not found for some reason. I want the exception to be propagated to the caller in such case. Ok. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. Added some
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Rob Crittenden wrote:
Jan Cholasta wrote:
Hi,
the attached patches implement automatic CA certificate renewal as well
as the initial version of the CA certificate management tool.
Requires my patches 172-196.
In order to test, you must install current git version of certmonger
(see https://fedorahosted.org/certmonger/ticket/26) and set SELinux to
permissive (see https://bugzilla.redhat.com/show_bug.cgi?id=1078783).
Make sure you install certmonger before running
ipa-server-install/ipa-replica-install. On F20 you can use RPMs located
at http://jcholast.fedorapeople.org/certmonger-git/.
To test automatic renewal, move system time forward (see
https://fedorahosted.org/freeipa/ticket/2803#comment:17 for more info
about certificate renewal testing, nickname of the CA certificate is
caSigningCert cert-pki-ca). In CA-full installs the renewal should be
fully automatic, in CA-less installs you should be alerted via syslog to
renew the certificate using ipa-cacert-manage.
To test manual renewal, run ipa-cacert-manage renew. You can run it on
any CA master. To make the renewed certificate available on other CA
masters, you must run getcert resubmit -d /etc/pki/pki-tomcat/alias -n
'caSigningCert cert-pki-ca' on each of them. Note that currently you
can't change the chaining of the CA certificate.
241
Not to be too anal, but would it be too outlandish to compare the
Authority Key Identifier (if there is one) with the Subject Key ID to
see if the cert is self-signed? Same subject then yeah, it is probably
self-signed. The keys match? Definitely.
242
I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) = handler(...)
rather than examining result[0], etc. That may be beyond the scope of
this patch though.
x509.normalize_certificate() can raise an exception, there should be a
try/except around it.
For an invalid cookie, please include the values seen in the environment
in the error message.
243
You are going to end up with a lot of acis with the same comment value.
Perhaps add the host in there as well.
These are not removed when a master is deleted.
244
There are now several different places where the caCertificate value is
updated. I wonder if it's time for a function. I found it it in
dsinstance.py, upload_cacert and now renew_ca_cert.
246
caRenewalMaster should be checked when a replica is deleted and moved to
another master. This is a good idea. I wonder if a ticket should be
opened to do something similar for CRL generation.
247
We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it might
be worth spitting out a waiting message, at least for debugging.
249
nss_init() is always scary to me since we can only have one. I didn't
see anything blow up, just wondering if this should be wrapped with an
is_initialized()-shutdown() at the top.
The find_cert_from_nickname() should be in a try/except in case the cert
is not found for some reason.
251
The tool should provide some feedback while it's running. For the
impatient (me) it takes a really long time and it's hard to know what is
going on, something in between nothing and full debug output.
The man page needs some more work too. I think some more explanation is
needed and an example would probably be really helpful as well. I think
particularly an example for external certs and a description of what you
mean by Self-signed CA (I assume you mean IPA-provided). I don't think
it really matters how many steps there are unless you are going to
provide progress output.
Got a backtrace when running as non-root:
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line
189, in validate_options
raise ScriptError('Must be root to run %s' % self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
252
In what context would this be executing? My guess is that certmonger is
trying to do the renewal but a new cert hasn't been issued yet, so this
gets sysloged?
Still doing functional testing.
My current scenario:
1. Newly installed IPA master with these patches.
2. Replica using IPA 3.3.4 (yeah, I cheated)
While doing time travel I had a single cert fail on the initial master
with this:
ca-error: Server at https://lyra.example.com/ipa/xml failed
request, will retry: 4204
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Jan Cholasta wrote:
Hi,
the attached patches implement automatic CA certificate renewal as well
as the initial version of the CA certificate management tool.
Requires my patches 172-196.
In order to test, you must install current git version of certmonger
(see https://fedorahosted.org/certmonger/ticket/26) and set SELinux to
permissive (see https://bugzilla.redhat.com/show_bug.cgi?id=1078783).
Make sure you install certmonger before running
ipa-server-install/ipa-replica-install. On F20 you can use RPMs located
at http://jcholast.fedorapeople.org/certmonger-git/.
To test automatic renewal, move system time forward (see
https://fedorahosted.org/freeipa/ticket/2803#comment:17 for more info
about certificate renewal testing, nickname of the CA certificate is
caSigningCert cert-pki-ca). In CA-full installs the renewal should be
fully automatic, in CA-less installs you should be alerted via syslog to
renew the certificate using ipa-cacert-manage.
To test manual renewal, run ipa-cacert-manage renew. You can run it on
any CA master. To make the renewed certificate available on other CA
masters, you must run getcert resubmit -d /etc/pki/pki-tomcat/alias -n
'caSigningCert cert-pki-ca' on each of them. Note that currently you
can't change the chaining of the CA certificate.
241
Not to be too anal, but would it be too outlandish to compare the
Authority Key Identifier (if there is one) with the Subject Key ID to
see if the cert is self-signed? Same subject then yeah, it is probably
self-signed. The keys match? Definitely.
242
I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) = handler(...)
rather than examining result[0], etc. That may be beyond the scope of
this patch though.
x509.normalize_certificate() can raise an exception, there should be a
try/except around it.
For an invalid cookie, please include the values seen in the environment
in the error message.
243
You are going to end up with a lot of acis with the same comment value.
Perhaps add the host in there as well.
These are not removed when a master is deleted.
244
There are now several different places where the caCertificate value is
updated. I wonder if it's time for a function. I found it it in
dsinstance.py, upload_cacert and now renew_ca_cert.
246
caRenewalMaster should be checked when a replica is deleted and moved to
another master. This is a good idea. I wonder if a ticket should be
opened to do something similar for CRL generation.
247
We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it might
be worth spitting out a waiting message, at least for debugging.
249
nss_init() is always scary to me since we can only have one. I didn't
see anything blow up, just wondering if this should be wrapped with an
is_initialized()-shutdown() at the top.
The find_cert_from_nickname() should be in a try/except in case the cert
is not found for some reason.
251
The tool should provide some feedback while it's running. For the
impatient (me) it takes a really long time and it's hard to know what is
going on, something in between nothing and full debug output.
The man page needs some more work too. I think some more explanation is
needed and an example would probably be really helpful as well. I think
particularly an example for external certs and a description of what you
mean by Self-signed CA (I assume you mean IPA-provided). I don't think
it really matters how many steps there are unless you are going to
provide progress output.
Got a backtrace when running as non-root:
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line
189, in validate_options
raise ScriptError('Must be root to run %s' % self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
252
In what context would this be executing? My guess is that certmonger is
trying to do the renewal but a new cert hasn't been issued yet, so this
gets sysloged?
Still doing functional testing.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Hi,
the attached patches implement automatic CA certificate renewal as well
as the initial version of the CA certificate management tool.
Requires my patches 172-196.
In order to test, you must install current git version of certmonger
(see https://fedorahosted.org/certmonger/ticket/26) and set SELinux to
permissive (see https://bugzilla.redhat.com/show_bug.cgi?id=1078783).
Make sure you install certmonger before running
ipa-server-install/ipa-replica-install. On F20 you can use RPMs located
at http://jcholast.fedorapeople.org/certmonger-git/.
To test automatic renewal, move system time forward (see
https://fedorahosted.org/freeipa/ticket/2803#comment:17 for more info
about certificate renewal testing, nickname of the CA certificate is
caSigningCert cert-pki-ca). In CA-full installs the renewal should be
fully automatic, in CA-less installs you should be alerted via syslog to
renew the certificate using ipa-cacert-manage.
To test manual renewal, run ipa-cacert-manage renew. You can run it on
any CA master. To make the renewed certificate available on other CA
masters, you must run getcert resubmit -d /etc/pki/pki-tomcat/alias -n
'caSigningCert cert-pki-ca' on each of them. Note that currently you
can't change the chaining of the CA certificate.
Honza
--
Jan Cholasta
From 3b3c5b99c1005a049436dc262cf8258daf7486c3 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Wed, 12 Mar 2014 11:41:02 +0100
Subject: [PATCH 01/13] Add function for checking if certificate is self-signed
to ipalib.x509.
---
ipalib/x509.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ipalib/x509.py b/ipalib/x509.py
index ca6eac5..8d049bd 100644
--- a/ipalib/x509.py
+++ b/ipalib/x509.py
@@ -164,6 +164,12 @@ def get_serial_number(certificate, datatype=PEM, dbdir=None):
del(nsscert)
return serial_number
+def is_self_signed(certificate, datatype=PEM, dbdir=None):
+nsscert = load_certificate(certificate, datatype, dbdir)
+self_signed = (nsscert.issuer == nsscert.subject)
+del nsscert
+return self_signed
+
def make_pem(data):
Convert a raw base64-encoded blob into something that looks like a PE
--
1.8.5.3
From 47635bbc42b36928d57ea48cfb6e40b621e6082a Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Tue, 18 Feb 2014 18:14:47 +0100
Subject: [PATCH 02/13] Support CA certificate renewal in
dogtag-ipa-ca-renew-agent.
---
.../certmonger/dogtag-ipa-ca-renew-agent-submit| 49 ++
1 file changed, 49 insertions(+)
diff --git a/install/certmonger/dogtag-ipa-ca-renew-agent-submit b/install/certmonger/dogtag-ipa-ca-renew-agent-submit
index 57eb4e5..8a1bd83 100755
--- a/install/certmonger/dogtag-ipa-ca-renew-agent-submit
+++ b/install/certmonger/dogtag-ipa-ca-renew-agent-submit
@@ -270,11 +270,60 @@ def export_csr():
return (ISSUED, cert)
+def renew_ca_cert():
+
+This is used for automatic CA certificate renewal.
+
+cert = os.environ.get('CERTMONGER_CERTIFICATE')
+if not cert:
+return (REJECTED, New certificate requests not supported)
+
+operation = os.environ.get('CERTMONGER_OPERATION')
+if operation == 'SUBMIT':
+result = retrieve_cert()
+if result[0] == ISSUED:
+new_cert = x509.normalize_certificate(result[1])
+old_cert = x509.normalize_certificate(cert)
+if new_cert != old_cert:
+return result
+
+state = 'retrieve'
+if x509.is_self_signed(cert):
+ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR)
+if ca.is_renewal_master():
+state = 'request'
+elif operation == 'POLL':
+cookie = os.environ.get('CERTMONGER_CA_COOKIE')
+if not cookie:
+return (UNCONFIGURED, Cookie not provided)
+
+state, sep, cookie = cookie.partition(':')
+if state not in ('retrieve', 'request'):
+return (UNCONFIGURED, Invalid cookie)
+
+os.environ['CERTMONGER_CA_COOKIE'] = cookie
+else:
+return (OPERATION_NOT_SUPPORTED_BY_HELPER,)
+
+if state == 'retrieve':
+result = retrieve_cert()
+elif state == 'request':
+os.environ['CERTMONGER_CA_PROFILE'] = 'caCACert'
+result = request_and_store_cert()
+
+if result[0] == WAIT:
+return (result[0], '%s:%s' % (state, result[1]))
+elif result[0] == WAIT_WITH_DELAY:
+return (result[0], result[1], '%s:%s' % (state, result[2]))
+else:
+return result
+
def main():
handlers = {
'ipaStorage': store_cert,
'ipaRetrieval': retrieve_cert,
'ipaCSRExport': export_csr,
+'ipaCACertRenewal': renew_ca_cert,
}
api.bootstrap(context='renew')
--
1.8.5.3
From 17c951b69870224adde95b8c919c7556a5890dcb Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Tue, 18 Feb 2014 18:15:49 +0100
Subject: [PATCH 03/13] Allow IPA master
