Bug 1881500 - Certmonger segfault after cert renewal request
Summary: Certmonger segfault after cert renewal request
Keywords:
Status: POST
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: certmonger
Version: 8.3
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: 8.5
Assignee: Rob Crittenden
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-22 14:26 UTC by Aleksandr Sharov
Modified: 2021-07-14 02:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Aleksandr Sharov 2020-09-22 14:26:24 UTC
Description of problem:
Command 

# ipa-getcert request -k /etc/pki/tls/private/cmgmr01.prod.csp.local.key -f /etc/pki/tls/certs/cmgmr01.prod.csp.local.pem 

gets certmonger to segfault with error:

Sep  9 12:48:01 cmgmr01 kernel: certmonger[14515]: segfault at 0 ip 00007f09ca36cdaa sp 00007ffe4d9358c8 error 4 in libc-2.17.so[7f09ca22e000+1c3000]
Sep  9 12:48:01 cmgmr01 systemd: certmonger.service: main process exited, code=killed, status=11/SEGV
Sep  9 12:48:01 cmgmr01 systemd: Unit certmonger.service entered failed state.
Sep  9 12:48:01 cmgmr01 systemd: certmonger.service failed.

Version-Release number of selected component (if applicable):
certmonger-0.78.4-12.el7.x86_64

How reproducible:
always

Steps to Reproduce:
Described earlier

Actual results:
Certmonger enters failed state after segfault

Expected results:
Certmonger handles command correctly

Additional info:
After failing, certmonger restarts normally and works fine until another request. Sosreport and coredump file are attached to the linked case.


[root@cmgmr01 chatfir]# getcert list
Number of certificates and requests being tracked: 2.
Request ID 'dogtag-ipa-renew-agent':
        status: NEED_KEY_PAIR
        stuck: no
        key pair storage: type=NONE
        certificate: type=FILE,location=''
        issuer:
        subject:
        expires: unknown
        pre-save command:
        post-save command:
        track: no
        auto-renew: no
Request ID '20180911095336':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/opt/cloudera/security/key.pem'
        certificate: type=FILE,location='/opt/cloudera/security/cert.pem'
        CA: IPA
        issuer: CN=Certificate Authority,O=PROD.CSP.LOCAL
        subject: CN=cmgmr01.prod.csp.local,O=PROD.CSP.LOCAL
        expires: 2022-09-09 14:57:40 UTC
        dns: cmgmr01.prod.csp.local
        principal name: host/cmgmr01.prod.csp.local@PROD.CSP.LOCAL
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

Comment 2 Rob Crittenden 2020-09-22 14:53:35 UTC
It is failing while iterating through the set of certificates due to the failed request 'dogtag-ipa-renew-agent'. Can you provide this request? It's in /var/lib/certmonger/requests/<some_id>. A simple grep for 'dogtag-ipa-renew-agent' should identify it from the other request.

#1  0x000055dc4032245d in base_add_request (conn=0x55dc420ebf10, 
    msg=0x55dc420ec450, ci=0x7ffe02627170, ctx=0x55dc420d2b50) at tdbush.c:681
681                     if (strcmp(cert_location, e->cm_cert_storage_location) != 0) {
(gdb) print cert_location
$3 = 0x55dc420dfce0 "/etc/pki/tls/certs/cmgmr01.prod.csp.local.pem"
(gdb) print e->cm_cert_storage_location
$4 = 0x0

Any guess how this request was made? It would help tighten up the code as it appears now to assume that this will always be set (which I can also fix).

I think to resolve this simply deleting the failed request will fix it but I'd like the chance to look at it first.

Comment 3 Aleksandr Sharov 2020-09-23 09:59:22 UTC
Hi Rob!

I've requested it from the client, you can see it attached to the case. 

Thank you!

Comment 4 Rob Crittenden 2020-09-23 12:54:38 UTC
It is safe to remove this with: getcert stop-tracking -i dogtag-ipa-renew-agent

That should fix things. I'm curious how this was created at all. It is effectively completely empty:

id=dogtag-ipa-renew-agent
key_type=UNSPECIFIED
key_gen_type=UNSPECIFIED
key_size=0
key_gen_size=0
key_next_type=UNSPECIFIED
key_next_gen_type=UNSPECIFIED
key_next_size=0
key_next_gen_size=0
key_preserve=0
key_storage_type=NONE
key_perms=0
key_requested_count=0
key_issued_count=0
cert_storage_type=FILE
cert_perms=0
cert_is_ca=0
cert_ca_path_length=0
cert_no_ocsp_check=0
last_need_notify_check=19700101000000
last_need_enroll_check=19700101000000
template_is_ca=0
template_ca_path_length=-1
template_no_ocsp_check=0
state=NEED_KEY_PAIR
autorenew=0
monitor=0
submitted=19700101000000

Comment 7 Rob Crittenden 2021-02-17 16:53:59 UTC
Cloned upstream to https://pagure.io/certmonger/issue/191

Comment 9 Rob Crittenden 2021-02-17 19:14:40 UTC
Moving to RHEL 8.

Comment 11 Rob Crittenden 2021-02-17 19:16:47 UTC
Upstream PR https://pagure.io/certmonger/pull-request/192

Comment 12 Petr Čech 2021-02-19 07:38:26 UTC
Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7.
Red Hat Enterprise Linux 7 is in Maintenance Support 2 Phase. This bug was reevaluated and will be postponed to RHEL 8.
Thank you for understanding.
Red Hat Enterprise Linux Identity Management Team

Comment 13 Rob Crittenden 2021-05-14 18:40:45 UTC
merged upstream: 0eec70b9dbd0a50a24fe173a68fd9ab72857e08d


Note You need to log in before you can comment on or make changes to this bug.