Intermittent Issues with 8152 Error frm NSS on SSL public / private key with PHP/Curl

10 views
Skip to first unread message

Craig Henry

unread,
Dec 9, 2020, 11:25:07 AM12/9/20
to dev-tec...@lists.mozilla.org
Hi,

This is my first post to this list so please be kind! I'm a PHP developer
by trade and not a server person.

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 XXXXXXXX > port 443 (#96)
* Trying XXXXXX
* Connected to XXXXXX (XXXXXXXXX) port 443 (#96)
* CAfile: /XXXXX_tlstrust.pem

CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=XXXXXXX
,O=XXXXXXXX,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: XXXXXXXX
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user 'XXXXXXXX'
> POST /XXXXXX/services HTTP/1.1
Authorization: Basic XXXXXXXXX
Host: XXXXXXXX
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=XXXXXXXX,OU=Buntingford,O=XXXXXXXXXX,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name: xxxxxxxx
* issuer: CN=XXXXXX,O=XXXXXXXX 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 XXXXXXXXXX port 443 (#81)
* Trying xxxxxxx...
* Connected to XXXXXXXXxxxxxxx(XXXXXX) port 443 (#81)
* CAfile: /XXXXXXXXX
xxxxxx
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=www.xxxxxxxxxxxx xxxxx
,O=XXXXXXn,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: XXXXXXXXXXXXXXX
* issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
* Server auth using Basic with user 'XXXXXXXXX'
> POST /XXXXX/services HTTP/1.1
Authorization: Basic xxxxxxxx
Host: XXXXXXXXX xxxxxxxxxx
Accept: */*
Content-Type:text/xml
Content-Length: 1019

* upload completely sent off: 1019 out of 1019 bytes
* NSS: client certificate from file
* subject: CN=XXXXXXXX,OU=Buntingford,O=XXXXXXXXXX Ltd,C=DE
* start date: Dec 03 10:01:35 2020 GMT
* expire date: Dec 01 10:01:35 2030 GMT
* common name:XXXXXXXXX
* issuer: CN=XXXXXXXXXxxxxxxx>,O=XXXXXXXXXXXX,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=/XXXXX; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
< Connection: close
<
* Closing connection 81

*Development Team*

*tassolutions <http://www.tas-solutions.co.uk/>*
the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK

*tel:* +44 (0)1621 857785 <+44%201621%20857785> - *www.tas-solutions.co.uk
<http://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.

<https://twitter.com/tassolutions>
<https://www.linkedin.com/company/tas-solutions>
<https://www.aito.com/aito-information/aito-business-partners>

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
<+44%201621%20857785>. 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 opened, internet
communications cannot be guaranteed to be secure or error-free and
therefore it is the responsibility of the recipient to ensure that they are
virus free. The sender therefore does not accept liability for any loss or
damage from receipt or use thereof which arises as a result of internet
transmission. Any views/opinions expressed within this e-mail and any
attachments are that of the individual and not necessarily that of TAS
Solutions Ltd.

Craig Henry

unread,
Dec 9, 2020, 11:29:24 AM12/9/20
to dev-tec...@lists.mozilla.org
The version we have running of NSS is 3.53.1-3.el7_9

Thanks


-Craig
On Thu, Dec 10, 2020 at 1:24 AM Craig Henry <cr...@tas-solutions.co.uk>
wrote:

Hubert Kario

unread,
Jan 5, 2021, 7:58:52 AMJan 5
to dev-tec...@lists.mozilla.org
On Wednesday, 9 December 2020 17:24:45 CET, Craig Henry wrote:
> Hi,
>
> This is my first post to this list so please be kind! I'm a PHP developer
> by trade and not a server person.
>
> 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.

that doesn't look like anytihng I've seen in our testing (and we test with
this
cipher suite quite extensively)

few things to consider:
* is the client connecting to exact same server every time?
some servers can advertise support for rsa-pss signatures even in TLS 1.2
while others do not—that may cause different behaviour even with the same
client key and cipher
* is the client private key stored in a file, in the nssdb or in a hardware
token (HSM, smartcard, or similar)?
* what's the bit size of the client modulus? is it 2048 bit exactly or is
it
slighly off, like 2047 bit?

difference on network level: comparison of packet traces for successful and
failed connection, may also be enlightening
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic

Reply all
Reply to author
Forward
0 new messages