Bug 1465804

This changes the default behavior of CRMFPopClient too.

Setup:

1. KRA's CS.cfg have those two parameters.

kra.allowEncDecrypt.archival=true
kra.allowEncDecrypt.recovery=true

2. It's being restarted after this change.
3. KRA rest info:
<KRAInfo><Attributes/><ArchivalMechanism>encrypt</ArchivalMechanism><EncryptAlgorithm>AES/CBC/PKCS5Padding</EncryptAlgorithm><RecoveryMechanism>encrypt</RecoveryMechanism><WrapAlgorithm>AES/CBC/PKCS5Padding</WrapAlgorithm></KRAInfo>

4. Restarted CA.

5. CA rest info:
<CAInfo><Attributes/><ArchivalMechanism>encrypt</ArchivalMechanism><EncryptAlgorithm>AES/CBC/PKCS5Padding</EncryptAlgorithm><WrapAlgorithm>AES/CBC/PKCS5Padding</WrapAlgorithm></CAInfo>

6. CRMFPopClient -d . -p SECret.123  -n "cn=aakkiang, uid=asha"  -q
POP_SUCCESS -b kra_transport.txt  -y -v -o crmf.req
Initializing security database: .
Loading transport certificate
Parsing subject DN
RDN: UID=asha
RDN: CN=aakkiang
Generating key pair
Keypair private key id: 6581d0caf2e94bf7ef842339078c78552a29dab4
Using key wrap algorithm: AES KeyWrap/Padding
Creating certificate request
CRMFPopClient: self_sign true. Generating SubjectKeyIdentifier extension.
CryptoUtil: createKeyIdentifier: begins
Creating signer
Creating POP
Creating CRMF request
Storing CRMF requrest into crmf.req


If we run ,

CRMFPopClient -d . -p SECret.456 -h "NHSM-GKAPOOR-SOFTCARD" -n "cn=foobartest" -m pki1.example.com:25443 -u caadmin -r caadmin -q POP_SUCCESS -w "AES/CBC/PKCS5Padding"  -o test.csr

ERROR: Any value specified for the key wrap parameter (-w) will be overriden.  CRMFPopClient will contact the CA to determine the supported algorithm when hostport is specified
Try 'CRMFPopClient --help' for more information.
ERROR: File 'transport.txt' does not exist
Try 'CRMFPopClient --help' for more information.


Looks like it needs attention .Not sure what all it might break!!

Additional information:

If we try to use -m option in CRMFPopClient is hanged so this is blocking QE testing.

CRMFPopClient -v -d . -p SECret.579 -h "NHSM6000-OCS" -n "cn=foobartest" -m nocp11.idm.lab.eng.rdu2.rhat.com:8443 -u caadmin -r caadmin -q POP_SUCCESS -b  kra_transport.txt -o test.csr
Initializing security database: .
Loading transport certificate
Parsing subject DN
RDN: CN=foobartest
Generating key pair
Keypair private key id: -39df806ca6a9a6bc41f9e9681e8c3a742294469c

^C[root@nocp11 cmctest]# CRMFPopClient -v -d . -p SECret.579 -h "NHSM6000-OCS" -n "cn=foobartest" -m nocp11.idm.lab.eng.rdu2.rhat.com:8443 -u caadmin -r caadmin -q POP_SUCCESS -b  kra_transport.txt -o test.csr
Initializing security database: .
Loading transport certificate
Parsing subject DN
RDN: CN=foobartest
Generating key pair
Keypair private key id: -39df806ca6a9a6bc41f9e9681e8c3a742294469c

java.lang.Exception: Failed to retrieve archive wrapping information from the CA: javax.ws.rs.ProcessingException: Unable to invoke request
	at com.netscape.cmstools.CRMFPopClient.getKeyWrapAlgotihm(CRMFPopClient.java:592)
	at com.netscape.cmstools.CRMFPopClient.main(CRMFPopClient.java:498)
Caused by: javax.ws.rs.ProcessingException: Unable to invoke request
	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:102)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62)
	at com.sun.proxy.$Proxy22.getInfo(Unknown Source)
	at org.dogtagpki.common.CAInfoClient.getInfo(CAInfoClient.java:45)
	at com.netscape.cmstools.CRMFPopClient.getKeyWrapAlgotihm(CRMFPopClient.java:580)
	... 1 more
Caused by: org.apache.http.NoHttpResponseException: The target server failed to respond
	at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
	at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
	at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
	at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
	at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
	at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
	at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
	at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
	at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:283)
	... 7 more
ERROR: Failed to retrieve archive wrapping information from the CA: javax.ws.rs.ProcessingException: Unable to invoke request
Try 'CRMFPopClient --help' for more information.

It needs attention so raising the priority of bug.You can lower it if it works or there is a workaround for it.

During TRIAGE, moved back from 7.5 ==> 7.4.z

Per discussions within the PKI Team, cancelling need for 7.4.z ZStream Batch Update 2.

Created attachment 1331549 [details]
debug logs snip

Ade, any idea how to address this issue?

[20171025] - RHEL 7.5 pre-Alpha Offline Triage ==> 7.6

alee: Not clear from the bug.  Is this blocking QE?  Or has this presumably been fixed?

It should not be a blocker since CRMFPopClient has facility to set keywrap algorithm. The bug is requesting similar support for the pki client.

Geetika,
Could you please confirm the following:
1. This bug is requesting for a feature for pki cli
2. In addition, you are also reporting that there is an issue with CRMFPopClient?
If so, I need more clarification.  I am having trouble understanding the issue.
Since this is different from "1" above, please file a separate bug against CRMFPopClient, and in this new bug,could you please provide complete setup information (anything that's changed from default), and all steps and log and/or output from commands.  thanks.

Hi Christina,

If we can fix pki client to have an option to set keywrap like crmfpopclient does using -w ,this bugzilla can be resolved.

CRMFPopClient throws wrapping issue if CA and KRA doesn't have same encrypt algorithm so I think just to have a correct error message will be useful.

Thanks

JUst tried the sample in scenario one. Seems to work:

pki -v -d . -c "secret123" -p 8080 client-cert-request  "CN=Test11,UID=Testing,OU=test" --profile caDualCert --type crmf --transport /tmp/kra.transport 
PKI options: -v -d . -c netscape
PKI command: 8080 -p 8080 client-cert-request CN=Test11,UID=Testing,OU=test --profile caDualCert --type crmf --transport /tmp/kra.transport
Java command: /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -Djava.ext.dirs=/usr/share/pki/lib -Djava.util.logging.config.file=/usr/share/pki/etc/logging.properties com.netscape.cmstools.cli.MainCLI -d . -c netscape --verbose -p 8080 client-cert-request CN=Test11,UID=Testing,OU=test --profile caDualCert --type crmf --transport /tmp/kra.transport
Server URL: http://localhost:8080
NSS database: /home/jmagne/.mozilla/firefox/9gpcudiw.default/.
Message format: null
Command: client-cert-request CN=Test11,UID=Testing,OU=test --profile caDualCert --type crmf --transport /tmp/kra.transport
Module: client
Module: cert-request
Initializing NSS
Logging into internal token
Using internal token
Initializing PKIClient
HTTP request: GET /pki/rest/info HTTP/1.1
  Accept: application/xml
  Accept-Encoding: gzip, deflate
  Host: localhost:8080
  Connection: Keep-Alive
  User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_181)
HTTP response: HTTP/1.1 200 
  Set-Cookie: JSESSIONID=B16463924FF9B92303C4C47F75C56AA1; Path=/pki; HttpOnly
  Content-Type: application/xml
  Content-Length: 106
  Date: Fri, 31 Aug 2018 18:50:11 GMT
HTTP request: GET /ca/rest/info HTTP/1.1
  Accept: application/xml
  Accept-Encoding: gzip, deflate
  Host: localhost:8080
  Connection: Keep-Alive
  User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_181)
HTTP response: HTTP/1.1 200 
  Set-Cookie: JSESSIONID=29800056FAB025C925BBB67DCBE1FE82; Path=/ca; HttpOnly
  Content-Type: application/xml
  Content-Length: 238
  Date: Fri, 31 Aug 2018 18:50:12 GMT
CSR:
MIIFSjCCBUYwggSsAgEBMIHigAECpTswOTENMAsGA1UECxMEdGVzdDEXMBUGCgmS
JomT8ixkAQETB1Rlc3RpbmcxDzANBgNVBAMTBlRlc3QxMaaBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAuhcTu2F09J7BQFZTPyO3pmVoxBUw18KrE3rVnbIoEJ0Q
VyaSM3U/fbqarnO1VgDPiFefjUyNxKsUAuSOzhz3AH/5J1OR3ob/XJTMJl1fnKC4
fMA5ga3XRqGzgNYcAQ88jzXvwtYbqc4zS0JYLODUsQYcqMIiZJyehG5ZW0kZgREC
AwEAATCCA8AwggO8BgkrBgEFBQcFAQSgggOtMIIDqaEVBglghkgBZQMEAQgECDSA
uQbukCxVgoIBAQAZYUTJl/c+CqzHeE0YWKp2ezCW+40xM0aCL7UIz+FWUvsHIMti
NPgYeb3a1IKYg48FxXhSSdW+9B7MjMY5fmT4mN56Kaesz8CqCggLOFLGYezHV7hX
rZTZY6DcQbQfS5tC1deVn4F0qwQG7MOEec91YG84+JknYs+Rcq38vN6lh1lQFnTi
6hM6KGm3LkSJzcZWLKS5h49dWOS6t3l3qryz5GaTIZgPFcG6h6nvs41m6xll8t+e
d6on0bdpWkGXzJUulbaHP/RqbBrxdZPWVctThGJPpWjsXQx6XJAmAjUYHf9Sd8ib
He8fk6hHgniAP9HJ0tPixub8YeQhzrwGKQZ4A4ICiQD7Hnc+gVE7gFn+VA0PLNu/
Q7uaLv485heNfitaYgszHzqDRtrFWyis0Q2JnuJYDlGpEd7UymkNyQG23c91MRjR
zPmrWvyqgGrt8EFp8+0IbyeamrSKp6t6GKnUISkJZUAryfk/A133SOf2uG0K0yZ/
if5bynbM87tv+z+TKVDDXLo27/D1Ijs6RFu+6nQ/gkGEN+n6SU7hQTN01RLylYKL
Rjw65WG9MAuejJZq0oPdFOp0dyJNyytUM/4ssBclcrP/EKWMVGnfTdxD1yko/UhV
8ocAGT7MHd1BqAfdFwj/bfWG54/uxbJRQcWJEJa+p8OcUBIrythkzAN+Fz5ugR5f
MP60wtpCX6rnEh3e6zxmP17/z8sZiEd6JsemjTxoEHN0d4J0V8IYB6/HJaHb5lN1
1z5TvtBaM5VvfnaXRskqvNDj/tM/aXecsFF3y5cOoytUUSldmISLtSV9yqKRob8v
r0QUS6rrJG2wehMRur22+y4X3bPwe0V8e5iOZ7GNmlZ6cWzGCio0our0Z667PjTC
A3yI61i9X+tvQcOS4X07xxjxraag0QeBhTEFxmegMTwe2qmr1VlrnMySMOaFPJtr
bqEEOENsCONDRPYLynnaG3ntRaAJ9A3GxvKO3JmOJLH/nVJlTmWMMv6rHt51BnBu
MRMOFhyp1Rm7hduyl3UmTb0c6PBk3txKRsmhQksPGHdA+Y0sCRyijimdbP2MA2u+
5PHbrDw4K/va2oErgPlA1uHIiA9xccDGZUrs3micx0ULtoL0FPzxKVyQa2S4OvXQ
XyCcxOO+s2uxzqJu0OAN8yN6Mup7WwkKvmqtYeHJ3Shzxj2ar89/5wYvBAVeV/+3
GkruxfPIlbuhgZMwDQYJKoZIhvcNAQELBQADgYEAdWxX5WLPxja/54+1vZ+eaAS/
Ly9oW+/5DL3rHl2NVTuNqJGkUulJm+pn4UM+Bry6ycHloURQmNtDJJMnAHakBBCI
Dutv1wrAg8lCtGcHYnAL10wKt+Ss/fX9NsDXp0Hah6BtnttTk2gs74ncsTBw8m1P
6ruEwPKIhUw2C+lYH3g=

Retrieving caDualCert profile.
HTTP request: GET /ca/rest/certrequests/profiles/caDualCert HTTP/1.1
  Accept: application/xml
  Accept-Encoding: gzip, deflate
  Host: localhost:8080
  Connection: Keep-Alive
  User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_181)
  Cookie: JSESSIONID=29800056FAB025C925BBB67DCBE1FE82
HTTP response: HTTP/1.1 200 
  Content-Type: application/xml
  Content-Length: 2563
  Date: Fri, 31 Aug 2018 18:50:12 GMT
Subject Name:
 - sn_uid: Testing
 - sn_cn: Test11
 - sn_ou: test
Sending certificate request.
HTTP request: POST /ca/rest/certrequests HTTP/1.1
  Accept: application/xml
  Accept-Encoding: gzip, deflate
  Content-Type: application/xml
  Content-Length: 4570
  Host: localhost:8080
  Connection: Keep-Alive
  User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_181)
  Cookie: JSESSIONID=29800056FAB025C925BBB67DCBE1FE82
HTTP response: HTTP/1.1 200 
  Content-Type: application/xml
  Content-Length: 735
  Date: Fri, 31 Aug 2018 18:50:14 GMT
-----------------------------
Submitted certificate request
-----------------------------
  Request ID: 15
  Type: enrollment
  Request Status: pending
  Operation Result: success

My CA rest info:

<CAInfo><Attributes/><ArchivalMechanism>keywrap</ArchivalMechanism><EncryptAlgorithm>AES/CBC/PKCS5Padding</EncryptAlgorithm><WrapAlgorithm>AES KeyWrap/Padding</WrapAlgorithm></CAInfo>

KRA rest info:

<KRAInfo><Attributes/><ArchivalMechanism>keywrap</ArchivalMechanism><EncryptAlgorithm>AES/CBC/PKCS5Padding</EncryptAlgorithm><RecoveryMechanism>keywrap</RecoveryMechanism><WrapAlgorithm>AES KeyWrap/Padding</WrapAlgorithm></KRAInfo>

One more data point:

The reason why the command in Comment #4 did not work was because the -m param for host:port uses an https port like 8443. The code seems to only support http. I suspect if 8080 is used, that command would work better. These kinds of connection error would explain many cases of the following error message:

ERROR: Failed to retrieve archive wrapping information from the CA: javax.ws.rs.ProcessingException: Unable to invoke request


I think what we need is a test case for that one where it actually fails due to mismatched wrapping algs and not just a connection error.

Also I have an explanation of this kind of error:

ERROR: Any value specified for the key wrap parameter (-w) will be overriden.  CRMFPopClient will contact the CA to determine the supported algorithm when hostport is specified
Try 'CRMFPopClient --help' for more information.


This appears to be by design in the code. When we put in a -m "host:port" parameter the code is designed to ignore the provided wrapping alg and query the host for it. The reason , once again, why that command failed was because an https port was given and not http. The servlet to get the wrapping alg was never even hit.

Hi Jack,

<error>

ERROR: Failed to retrieve archive wrapping information from the CA: javax.ws.rs.ProcessingException: Unable to invoke request

</error>

This error occurs when there is mismatch in CA and KRA algorithms.
This directly throws an error which never indicates the actual problem and I thought this could be needed for CC purpose.logs(both debug and audit) doesn't have a problem information about point of failures.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.