[Freeipa-devel] [PATCHES] 241-253 CA certificate renewal

Rob Crittenden rcritten at redhat.com
Thu Apr 24 21:16:17 UTC 2014


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, is_renewal_master() for
>> example.
>
> They are defined in patch 246.1 (now 246.2).
>
>>
>> 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...". 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 
(src/lxml/lxml.etree.c:96504)
[Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692]   File 
"parser.pxi", line 582, in 
lxml.etree._ParserContext._handleParseResultDoc 
(src/lxml/lxml.etree.c:91308)
[Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692]   File 
"parser.pxi", line 683, in lxml.etree._handleParseResult 
(src/lxml/lxml.etree.c:92494)
[Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692]   File 
"parser.pxi", line 633, in lxml.etree._raiseParseError 
(src/lxml/lxml.etree.c:91957)
[Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: None
[Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: 
[xmlserver] host/lyra.greyoak.com at GREYOAK.COM: 
cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8VPZgm!
 3VCtgMvPVk
3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', 
principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, 
version=u'2.51'): XMLSyntaxError

I noticed that in the external CA case we still have certmonger tracking 
the CA. What will it do at expiration?

>> I updated selinux-policy but I'm not seeing the certs added consistently
>> to ca_renewal so there is nothing to do, so it sits in CA_WORKING. I
>> verified it isn't a replication issue, the replication is working fine,
>> the certs just weren't pushed.
>
> Fixed renewal scripts not to use ldapi, see patch 264.

Renewal in the self-signed case is working a lot smoother now.

> Also fixed certificate retrieval from LDAP to check if the certificate
> was actually renewed, see patch 265.

/etc/ipa/ca.crt isn't being updated on renewal.

rob




More information about the Freeipa-devel mailing list