Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

2020-12-09 Thread Benjamin Kaduk via openssl-users
Hi Craig,

On Wed, Dec 09, 2020 at 08:35:46PM +0900, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior connecting
> to a 3rd party of the key being rejected with a 8152 error - "The key does
> not support the requested operation". Other times it works OK.
> 
> We have another user who is using this 3rd party and same connection type
> but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?

As was already noted, this is not an error generated by OpenSSL.
More concretely, RFC 8152 is for CBOR Object Signing and Encryption (COSE), 
which is not really
related to TLS at all.  I suspect the error is not from NSS or CURL either but
rather from a COSE implementation.

-Ben


Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

2020-12-09 Thread Matt Caswell



On 09/12/2020 11:35, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior
> connecting to a 3rd party of the key being rejected with a 8152 error -
> "The key does not support the requested operation". Other times it works
> OK.

That error does not come from OpenSSL. It appears to be an NSS error. So
I'd suggest asking on an NSS or CURL forum.

Matt



> 
> We have another user who is using this 3rd party and same connection
> type but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
> 
> The CURL logs are below but altered for privacy reasons.
> 
> Thanks
> 
> 
> 
> -Craig
> 
> 
> 
> 
> 
> 
> 
> *Key blocked response*
> 
> * About to connect() to  port 443 (#96)
> *   Trying XX
> * Connected to XX (X) port 443 (#96)
> *   CAfile: /X_tlstrust.pem
> 
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXX
> ,O=,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name:  
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user ''
>> POST /XX/services HTTP/1.1
> Authorization: Basic X
> Host:  
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: 
> * issuer: CN=XX ,O= GmbH,L=Bad
> Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
> 
> 
> *Successful response*
> 
> * About to connect() to XX port 443 (#81)
> *   Trying xxx...
> * Connected to   (XX) port 443 (#81)
> *   CAfile:
> /X
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.
> ,O=XXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'X'
>> POST /X/services HTTP/1.1
> Authorization: Basic 
> Host: X 
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:X
> * issuer: CN=X ,O=,L=Bad
> Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com
>  *.klarna.com 
> *.masterpass.com  *.mastercard.com
>  *.npci.org.in  'unsafe-eval'
> 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
> Path=/X; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> <
> * Closing connection 81
> 
> 
> 
> 
> 
> *Development Team*
> 
> *tassolutions *
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK
> 
> *tel:*   +44 (0)1621 857785   -
> *www.tas-solutions.co.uk *
> 
> *Our business | support hours are Monday - Frida

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

2020-12-09 Thread Tomas Mraz
Hi,

curl on RHEL-7 and Centos 7 uses NSS and not OpenSSL as the TLS
backend. So this is unfortunately a wrong mailing list to ask.

Tomas Mraz

On Wed, 2020-12-09 at 20:35 +0900, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos 
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http
> basic auth
> 
> We're having an issue where we are seeing intermittent behavior
> connecting to a 3rd party of the key being rejected with a 8152 error
> - "The key does not support the requested operation". Other times it
> works OK. 
> 
> We have another user who is using this 3rd party and same connection
> type but not reported this issue. 
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
> 
> The CURL logs are below but altered for privacy reasons. 
> 
> Thanks
> 
> 
> 
> -Craig
> 
> 
> 
> 
> 
> 
> 
> Key blocked response
> 
> * About to connect() to  port 443 (#96)
> *   Trying XX
> * Connected to XX (X) port 443 (#96)
> *   CAfile: /X_tlstrust.pem
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXX,O=,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: 
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user ''
> > POST /XX/services HTTP/1.1
> Authorization: Basic X
> Host: 
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: 
> * issuer: CN=XX,O= GmbH,L=Bad Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
> 
> 
> Successful response
> 
> * About to connect() to XX port 443 (#81)
> *   Trying xxx...
> * Connected to  (XX) port 443 (#81)
> *   CAfile: /X
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.,O=XXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'X'
> > POST /X/services HTTP/1.1
> Authorization: Basic 
> Host: X
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:X
> * issuer: CN=X,O=,L=Bad Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500 
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com
> *.klarna.com *.masterpass.com *.mastercard.com *.npci.org.in 'unsafe-
> eval' 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-
> api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*;
> q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie:
> JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s; Path=/X;
> Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> < 
> * Closing connection 81
> 
> 
> 
> 
> 
> Development Team
> 
> tassolutions
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le
> | UK
> 
> tel:   +44 (0)1621 857785  - www.tas-solutions.co.uk
> 
> Our business | support hours are Monday - Friday 9.00am to 5.30pm
> 
> Offices are closed on all UK Bank Holidays.
> 
> Support outside these hours can be arranged on request.
> 
>
> 
> This E-mail and any attachments contain confidential and proprietary
> information of TAS Solutions Ltd and are intended only for the use of
> the person/s to whom it is addressed. If you have received this E-
> mail in error please immediately notify support by telephone on +44
> (0)1621 857785. Although this e-mail and any attachments are believed
> to be free of any virus, or other defect which might affect any
> computer or system into which they are received and o

Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

2020-12-09 Thread Craig Henry
Hi,

This is my first post to this list so please be kind!

Environment - Linux Centos
SSL - 1.0.2k19-el7

Connection - CURL (via PHP) with public / private key auth + http basic auth

We're having an issue where we are seeing intermittent behavior connecting
to a 3rd party of the key being rejected with a 8152 error - "The key does
not support the requested operation". Other times it works OK.

We have another user who is using this 3rd party and same connection type
but not reported this issue.

Has anyone got any clue as to what might be causing this type of
intermittent connection issue ?

The CURL logs are below but altered for privacy reasons.

Thanks



-Craig







*Key blocked response*

* About to connect() to   port 443 (#96)
*   Trying XX
* Connected to XX (X) port 443 (#96)
*   CAfile: /X_tlstrust.pem

  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=XXX 
,O=,L=Atlanta,ST=Georgia,C=US
* start date: Jun 17 00:00:00 2020 GMT
* expire date: Jun 18 12:00:00 2022 GMT
* common name:  
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user ''
> POST /XX/services HTTP/1.1
Authorization: Basic X
Host:  
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=,OU=Buntingford,O=XX,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name: 
* issuer: CN=XX ,O= GmbH,L=Bad
Vilbel,ST=Hessen,C=DE
* SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
* The key does not support the requested operation.
* Closing connection 96


*Successful response*

* About to connect() to XX port 443 (#81)
*   Trying xxx...
* Connected to   (XX) port 443 (#81)
*   CAfile: /X

  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=www. 
,O=XXn,L=Atlanta,ST=Georgia,C=US
* start date: Jun 17 00:00:00 2020 GMT
* expire date: Jun 18 12:00:00 2022 GMT
* common name: XXX
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user 'X'
> POST /X/services HTTP/1.1
Authorization: Basic 
Host: X 
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name:X
* issuer: CN=X ,O=,L=Bad
Vilbel,ST=Hessen,C=DE
< HTTP/1.1 500
< Date: Tue, 08 Dec 2020 13:42:26 GMT
< Server: Apache
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: default-src 'self' *.googleapis.com *.klarna.com
*.masterpass.com *.mastercard.com *.npci.org.in 'unsafe-eval'
'unsafe-inline'; frame-ancestors 'self'
< X-Application-Context: application:spring-boot,node-global,node-api:8843
< Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
< SOAPAction: ""
< Expires: 0
< Content-Type: text/xml;charset=utf-8
< Content-Length: 1481
< Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
Path=/X; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
< Connection: close
<
* Closing connection 81





*Development Team*

*tassolutions *
the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK

*tel:*   +44 (0)1621 857785 <+44%201621%20857785>  - *www.tas-solutions.co.uk
*

*Our business | support hours are Monday - Friday 9.00am to 5.30pm*

Offices are closed on all UK Bank Holidays.

Support outside these hours can be arranged on request.





This E-mail and any attachments contain confidential and proprietary
information of TAS Solutions Ltd and are intended only for the use of the
person/s to whom it is addressed. If you have received this E-mail in error
please immediately notify support by telephone on