Bug 1807691
| Summary: | Vague error message: ca-error: Error: failed to verify signature on server response. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Graham Leggett <minfrin> |
| Component: | certmonger | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.4 | CC: | ksiddiqu, myusuf, nalin, pcech, rcritten |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | certmonger-0.79.7-8.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 02:51:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1825061 | ||
|
Description
Graham Leggett
2020-02-26 23:35:40 UTC
Look in syslog for more information on what failed. Syslog logs the following: Feb 26 23:32:16 bob certmonger[3888]: 2020-02-26 23:32:16 [3888] Error: failed to verify signature on server response. Alas, in the absence of a proper error message, we're nowhere. Looking at the code at https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_1065, we have examples as follows: if (PKCS7_verify(p7, certs, store, NULL, out, 0) != 1) { cm_log(1, "Message failed verification.\n"); goto done; } It looks like this code is ignoring the errors returned from openssl, and just returning the string "Message failed verification.\n", am I reading this correctly? But you aren't even seeing that message are you? Try stopping certmonger, find the CA you added in /var/lib/certmonger/cas and find the ca_external_helper line. Add -v to the options to scep-submit and restart certmonger. ca_external_helper=/usr/libexec/certmonger/scep-submit -v -u http://.... Resubmit the request with: getcert resubmit -i test.example.com See if you at least get additional output in the log. Unfortunately pagure does not have any obvious search functionality, and none of the source code is indexed by google, so I can't find the message at all.
Next step, check out the code and use old fashioned grep, and we find this:
ERR_clear_error();
i = cm_pkcs7_verify_signed((unsigned char *) results2, results_length2,
cacerts, racerts,
NID_pkcs7_data, ctx, NULL,
&tx, &msgtype, &pkistatus, &failinfo,
&sender_nonce, &sender_nonce_length,
&recipient_nonce, &recipient_nonce_length,
&payload, &payload_length);
if (i != 0) {
printf(_("Error: failed to verify signature on "
"server response.\n"));
cm_log(1, "Error: failed to verify signature on "
"server response.\n");
while ((error = ERR_get_error()) != 0) {
memset(buf, '\0', sizeof(buf));
ERR_error_string_n(error, buf, sizeof(buf));
cm_log(1, "%s\n", buf);
}
s = cm_store_base64_from_bin(ctx, (unsigned char *) results2,
results_length2);
s = cm_submit_u_pem_from_base64("PKCS7", 0, s);
fprintf(stderr, "%s", s);
cm_log(1, "%s", s);
free(s);
return CM_SUBMIT_STATUS_UNREACHABLE;
}
Reading the code, we cm_log() telling us that the signature verification failed, and then we print out the openssl error stack only to find according to openssl that the error stack is empty and there is nothing wrong with the signature verification after all, _or_ the output of printf is reaching syslog, but the out of cm_log is going to /dev/null.
> Try stopping certmonger, find the CA you added in /var/lib/certmonger/cas and find the ca_external_helper line.
>
> Add -v to the options to scep-submit and restart certmonger.
>
> ca_external_helper=/usr/libexec/certmonger/scep-submit -v -u http://....
>
> Resubmit the request with: getcert resubmit -i test.example.com
>
> See if you at least get additional output in the log.
Did all of this, there is no additional output in the log.
None of this should be necessary in response to a signature verification failure, the error message should just tell me what I need to know.
Digging further into the code, it looks like we try to log the openssl error stack twice, the first time is here: https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_1157 if (ret != 0) { while ((error = ERR_get_error()) != 0) { ERR_error_string_n(error, buf, sizeof(buf)); cm_log(1, "%s\n", buf); } } The second time is here: https://pagure.io/certmonger/blob/master/f/src/scep.c#_938 Analysing the use of cm_log(), it looks like every single pkcs7 related error message is suppressed by default. Looking at these messages, all of them should be logged by default: Little-Net:certmonger-master minfrin$ grep -r cm_log\( src/pkcs7.c src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing recipient certificate.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error encrypting signing request.\n"); src/pkcs7.c: cm_log(1, "Error encoding encrypted signing request.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error encoding encrypted signing request.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing certificate signing request.\n"); src/pkcs7.c: cm_log(1, "Error encoding certificate signing request.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error encoding certificate signing request.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing CA certificate.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing client certificate.\n"); src/pkcs7.c: cm_log(1, "Error encoding CA certificate issuer name.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error encoding CA certificate issuer name.\n"); src/pkcs7.c: cm_log(1, "Error encoding client certificate subject name.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error encoding client certificate subject name.\n"); src/pkcs7.c: cm_log(1, "Error encoding issuer and subject names.\n"); src/pkcs7.c: cm_log(1, "Error parsing what should be PKCS#7 signed-data.\n"); src/pkcs7.c: cm_log(1, "PKCS#7 data is not signed-data.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing chain certificate.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Error parsing chain certificate.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "Message failed verification.\n"); src/pkcs7.c: cm_log(1, "Number of PKCS#7 signed-data signers != 1.\n"); src/pkcs7.c: cm_log(1, "Error parsing PKCS#7 encapsulated content.\n"); src/pkcs7.c: cm_log(1, "PKCS#7 encapsulated data is not %s (%s).\n", src/pkcs7.c: cm_log(1, "PKCS#7 signed-data contains no signed attributes.\n"); src/pkcs7.c: cm_log(1, "Out of memory.\n"); src/pkcs7.c: cm_log(1, "%s\n", buf); I suspect there has been a lot of cut and paste having gone on over time, the log levels don't seem to make any coherent sense. Another observation - the act of restarting certmonger causes any extra -v parameters that were added to ca_external_helper to be removed. Time to bring out the sledgehammer, we apply the following patch to completely disable the verbose mechanism, and log absolutely everything:
[root@bob ~]# cat ~minfrin/rpmbuild/SOURCES/0030-loglevel.patch
--- src/log.c-orig 2020-02-27 11:22:55.174314190 +0000
+++ src/log.c 2020-02-27 11:23:18.652280148 +0000
@@ -63,7 +63,7 @@
char *p;
struct tm lt;
time_t now;
- if (level <= cm_log_level) {
+ if (1) {
stream = stderr;
switch (cm_log_method) {
case cm_log_none:
Some observations:
- Despite hard coding all logging to on, we see no openssl error messages at all. There is complete silence.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14145] Redirecting stdin and stderr to /dev/null, leaving stdout open for child "/usr/libexec/c
ertmonger/scep-submit".
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Request1('test.example.com') moved to state 'SUBMITTING'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit Request1('test.example.com') on traffic from 15.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').capabilities moved to state 'REFRESHING'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').capabilities on traffic from 87.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').capabilities data is unchanged
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').capabilities moved to state 'NEED_TO_ANALYZE'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').capabilities now.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').capabilities now.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Waiting for instructions for CA6('Redwax Interop').capabilities.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').encryption_certs moved to state 'REFRESHING'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').encryption_certs on traffic from 89.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').encryption_certs data is unchanged
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').encryption_certs moved to state 'NEED_TO_ANALYZE'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').encryption_certs now.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').encryption_certs moved to state 'ANALYZING'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').encryption_certs on traffic from 11.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14147] Certificate "RA certificate" valid for 629716781s.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14147] Certificate "CA certificate" valid for 629355885s.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14147] Result is 2212159136000000.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] CA6('Redwax Interop').encryption_certs moved to state 'NEED_TO_REFRESH'
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit CA6('Redwax Interop').encryption_certs in 31536000 seconds.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Certificate submission still ongoing.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Will revisit Request1('test.example.com') on traffic from 15.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Certificate submission attempt complete.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Child status = 3.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Child output:
Feb 27 11:34:10 bob certmonger[14096]: "Error: failed to verify signature on server response.
Feb 27 11:34:10 bob certmonger[14096]: "
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Error: failed to verify signature on server response.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Certificate not (yet?) issued.
Feb 27 11:34:10 bob certmonger[14096]: 2020-02-27 11:34:10 [14096] Request1('test.example.com') moved to state 'CA_UNREACHABLE'
- There is a clue on this line though:
Redirecting stdin and stderr to /dev/null, leaving stdout open for child "/usr/libexec/certmonger/scep-submit".
It looks like everything from scep-submit is being dumped to /dev/null as I suspected above, and as a result the errors are being discarded, regardless of the debug level.
https://pagure.io/certmonger/blob/master/f/src/submit-e.c#_944
Next step, increase the size of the hammer from sledgehammer to pneumatic hammer:
--- src/log.c-orig 2020-02-27 12:27:53.574607567 +0000
+++ src/log.c 2020-02-27 12:30:28.292381326 +0000
@@ -63,6 +63,10 @@
char *p;
struct tm lt;
time_t now;
+
+level = 0;
+cm_log_method = cm_log_syslog;
+
if (level <= cm_log_level) {
stream = stderr;
switch (cm_log_method) {
Feb 27 14:11:44 bob certmonger[5017]: Redirecting stdin and stderr to /dev/null, leaving stdout open for child "/usr/libexec/certmonger/scep-submit".
Feb 27 14:11:44 bob certmonger[5017]: Running enrollment helper "/usr/libexec/certmonger/scep-submit".
Feb 27 14:11:44 bob certmonger[4954]: Request1('test.example.com') moved to state 'SUBMITTING'
Feb 27 14:11:44 bob certmonger[4954]: Will revisit Request1('test.example.com') on traffic from 16.
Feb 27 14:11:44 bob scep-submit[5017]: Checking server capabilities list for "Renewal"
Feb 27 14:11:44 bob scep-submit[5017]: found it.
Feb 27 14:11:44 bob scep-submit[5017]: Message failed verification.
Feb 27 14:11:44 bob scep-submit[5017]: error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found
Feb 27 14:11:44 bob scep-submit[5017]: Error: failed to verify signature on server response.
Success - we have an openssl message.
So, it looks like these three lines need to be returned from scep-submit to certmonger, and not just the last line:
Feb 27 14:11:44 bob scep-submit[5017]: Message failed verification.
Feb 27 14:11:44 bob scep-submit[5017]: error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found
Feb 27 14:11:44 bob scep-submit[5017]: Error: failed to verify signature on server response.
In addition, there needs to be some way for scep-submit to log something. Right now it logs to stderr, and then that is diverted to /dev/null.
This should fix the logging (untested):
diff --git a/src/scep.c b/src/scep.c
index b37711cf..697dc83c 100644
--- a/src/scep.c
+++ b/src/scep.c
@@ -302,6 +302,11 @@ main(int argc, const char **argv)
bindtextdomain(PACKAGE, MYLOCALEDIR);
#endif
+ if (isatty(STDERR_FILENO))
+ cm_log_set_method(cm_log_stderr);
+ else
+ cm_log_set_method(cm_log_syslog);
+
pctx = poptGetContext(argv[0], argc, argv, popts, 0);
if (pctx == NULL) {
return CM_SUBMIT_STATUS_UNCONFIGURED;
certmonger writes its state information out to the request and ca files on shutdown. I suspect that is where the -v got lost.
The closing of stdout/stderr for helpers is fixed in 0.79.9+
This patch fixes half the problem, I still need ths following patch to work around the lack of control over the debug level:
--- src/log.c-orig 2020-02-27 15:23:42.290510231 +0000
+++ src/log.c 2020-02-27 15:24:03.750479790 +0000
@@ -63,6 +63,9 @@
char *p;
struct tm lt;
time_t now;
+
+level = 0;
+
if (level <= cm_log_level) {
stream = stderr;
switch (cm_log_method) {
Upstream PR https://pagure.io/certmonger/pull-request/145 Small detail in the PR - the -v flag is passed just once, but passing it multiple times ups the debugging level. Is this intended? It's a step forward. In the case of scep-submit the only log levels are 0 and 1 so a single -v is sufficient to get all possible output. It seemed like overkill, though arguably more correct, to loop and add the additional v's when they would have no impact. cm_log() probably needs an overhaul to not use raw integers to specify log level but an enum or other definition. A pass to ensure consistency and reasonable default values is also necessary based on the scep-submit experience. As part of this I'm considering dropping the helper -v in favor of a single debug level specified to certmonger itself. This disconnect has been confusing for many and the only advantage it seems to have is to be able to do more fine-grained debug tuning per helper. In the big scope of things I'm not sure how handy that is. But I think this PR will clear up the biggest issues anyway. Makes sense. My patch hard coding the level to zero is working for me for now. I reproduced this using AD CS with a root and a subordinate on an IPA installed machine. Install a standalone CA on one AD server (domain enrollment shouldn't make a difference). Use this to sign a second AD CA CA as a standalone, subordinate. Install the Network Device Enrollment Service (this is SCEP) on the subordinate. I used the SSSD test suite to setup the basic infrastructure, https://github.com/SSSD/sssd-test-suite, then setup the standalone CA on the root, then the standalone subordinate on the child and use the client instance to do the testing. 1. Setup a SCEP server (e.g. AD CS) 2. Add as a SCEP CA specifying the other certs file be the IPA CA (to throw off signing verification). Be sure to use the unencrypted HTTP channel to make things simpler. getcert add-scep-ca -c SCEP -u http://ad.example.test/certsrv/mscep/mscep.dll/pkiclient.exe -R /etc/scep/child-ca.pem -I /etc/ipa/ca.crt -v Strictly speaking you should be able to use any valid cert for -I. I used the IPA cert since my test machine was already enrolled. 3. Get a PIN from the CA 4. Request a cert getcert request -c SCEP -d /etc/pki/nssdb -n Server-Cert -I scep -L <PIN> 5. The request should fail with CA_UNREACHABLE with a ca-error of "Error: failed to verify signature on server response." The fixed package will include the last error that OpenSSL logged (if any) on the end of the above message. It should look something like: error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error This will also be available in the journal: Apr 14 15:40:16 child.client.vm scep-submit[405417]: Message failed verification. Apr 14 15:40:16 child.client.vm scep-submit[405417]: Error: failed to verify signature on server response. Apr 14 15:40:16 child.client.vm scep-submit[405417]: error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error <the PKCS7 message> Also fixed is passing -v to the helper. In the past this was silently dropped, visible only if you ran a separate dbus session. This patch will include -v as a call to the helper thus increasing debug output (in this case there is no additional output to be seen). You can verify that this is fixed with: grep helper `grep -l SCEP /var/lib/certmonger/cas/*` It should contain the -v when the scep CA was added (or however many you passed in). Additional info: You can obtain the CA and CA certs from the SCEP server using: /usr/libexec/certmonger/scep-submit -u http://child-dc/certsrv/mscep/mscep.dll/pkiclient.exe -C The order of the 4 certs returned should be: root RA, root CA, child RA, child CA To get the PIN to go to the SCEP url in a browser to see the administrative interface (I used IE on the AD machine). You want a challenge password. Alternatively you might try to use dogtag for the SCEP server but you'll need to use it in RHEL 7.x. The error isn't specifically related to having a subordinate, I was trying to more closely match the reporter's environment. Fixed in upstream master: f9342db638cc9a8a312f19cc019f05824bcd3b7c 58cc1f2638f7c369fddb8daaff5b953105365a23 3881b8a968248702d7c2bc504a0495d5fdf21a8d version: certmonger-0.79.7-14.el8.x86_64 Steps: 1. Setup IPA server 2. get the scep server certs and save to a file. $ /usr/libexec/certmonger/scep-submit -u <URL> -C 3. first certificate is RA from above command, we need only RA certificate put that in a file(pay attention where you storing cert. Should have right SElinux context) 4. add scep server with this RA and ipa's ca cert $ getcert add-scep-ca -c "Redwax Interop" -u <URL> -N /etc/ipa/ca.crt -r <path-to-cert-from-3> -R /etc/ipa/ca.crt -I /etc/ipa/ca.crt 5. Request a certificate Actual result: [root@master ~]# /usr/libexec/certmonger/scep-submit -u http://interop.redwax.eu/test/simpleDD/scep -C > /etc/pki/tls/certs/rw-ra.crt (removed all the certificate from file except first one (RA)) [root@master ~]# getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep -N /etc/ipa/ca.crt -r /etc/pki/tls/certs/rw-ra.crt -R /etc/ipa/ca.crt -I /etc/ipa/ca.crt New CA "Redwax Interop" added. [root@master ~]# getcert request -f /etc/pki/tls/certs/test.example.com.cert -k /etc/pki/tls/certs/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 4096 -u digitalSignature -u keyEncipherment -L challenge -v New signing request "test.example.com" added. [root@master ~]# [root@master ~]# getcert list -i test.example.com Number of certificates and requests being tracked: 10. Request ID 'test.example.com': status: CA_UNREACHABLE ca-error: Error: failed to verify signature on server response. error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error stuck: no key pair storage: type=FILE,location='/etc/pki/tls/certs/test.example.com.key' certificate: type=FILE,location='/etc/pki/tls/certs/test.example.com.cert' signing request thumbprint (MD5): 4F46B48B 18616403 6666A2A1 12D485EB signing request thumbprint (SHA1): 0081B5C7 452792AA A643714F 9338B5F2 9D4546C9 CA: Redwax Interop issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes [root@master ~]# The error specify the cause of failure. Hence marking the bug as verified. Reproducer: ~~~~~~~~~~~ version: certmonger-0.79.7-6.el8.x86_64 on rhel8.2 [root@master ~]# /usr/libexec/certmonger/scep-submit -u http://interop.redwax.eu/test/simple/scep -C > /etc/pki/tls/certs/rw-ra.crt [root@master ~]# getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep -r /etc/pki/tls/certs/rw-ra.crt -R /etc/ipa/ca.crt -I /etc/ipa/ca.crt New CA "Redwax Interop" added. [root@master ~]# [root@master ~]# getcert request -f /etc/pki/tls/certs/test.example.com.cert -k /etc/pki/tls/certs/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 4096 -u digitalSignature -u keyEncipherment -L challenge -v New signing request "test.example.com" added. [root@master ~]# [root@master ~]# [root@master ~]# getcert list -i test.example.com Number of certificates and requests being tracked: 10. Request ID 'test.example.com': status: CA_UNREACHABLE ca-error: Error: failed to verify signature on server response. stuck: no key pair storage: type=FILE,location='/etc/pki/tls/certs/test.example.com.key' certificate: type=FILE,location='/etc/pki/tls/certs/test.example.com.cert' signing request thumbprint (MD5): B7817E87 6F9E4B69 66A97E71 1EE01BDD signing request thumbprint (SHA1): 2DFD053D CE9C1436 E38BEC94 7F6DA952 D51B7218 CA: Redwax Interop issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (certmonger bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4671 |