Curl error 58 unable to set private key file

I’m trying to connect to a remote host using cURL. The connection requires the use of a certificate and a private key which is password protected. So far I’m unsuccessful with this code below:

<?php
    $wsdl       = 'https://domain.com/?wsdl';
    $certFile   = getcwd() . '/auth/cert.pem';
    $keyFile    = getcwd() . '/auth/key.pem';
    $password   = 'pwd';

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL,           $wsdl);
    curl_setopt($ch, CURLOPT_SSLCERT,       $certFile);
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD,  $password);
    curl_setopt($ch, CURLOPT_SSLKEY,        $keyFile);
    #curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);
    #curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    #curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $output = curl_exec($ch);

    var_dump(curl_errno($ch));
    var_dump(curl_error($ch));

The result I keep getting is error 58: unable to set private key file: '/home/.../domains/.../public_html/auth/key.pem' type PEM.

Things I’ve tried so far:

• Check if the key-file is readable as suggested here: Unable to use libcurl to access a site requiring client authentication. Trying to pass the file through openssl_private_key() gives me a resource, and not a boolean. So this seems good.
• Switch the order of the content in the key.pem file as suggested here: Unable to use libcurl to access a site requiring client authentication. No luck so far.
• Played around with some other options like SLL_VERIFY_PEER, SSL_VERIFY_HOST, SSL_CERTTYPE and other options which seemed trivial regarding the official PHP-docs. No luck so far.

I’m pretty sure the problem lies somehwere in my configuration, but I’m not sure where to look.

Unable to set private key file curl error

I fixed my problem, when a create my own private.key to create my cert.pem don´t work but When I generate automatically with the page of visa (the private key) its work. and Also work when i do method GET .

When I do POST. I copy the sample parameters that show visa developer, but show an error

I think that I should change the structure the sample parametres of visa:

• Mark as New
• Bookmark
• Subscribe
• Subscribe to RSS Feed
• Permalink
• Print
• Report Inappropriate Content

Great to hear that you have fixed your private key issue.

I tried the parameters that you were using and copied it to my testing tool and I was able to get a response successfully. Here’s my post request and response:

End Point https://sandbox.api.visa.com/visadirect/fundstransfer/v1/pullfundstransactions
Method POST
Request
<
«amount»: «124.02»,
«localTransactionDateTime»: «2020-07-15T02:46:25»,
«cardAcceptor»: <
«address»: <
«country»: «USA»,
«zipCode»: «94404»,
«county»: «081»,
«state»: «CA»
>,
«idCode»: «ABCD1234ABCD123»,
«name»: «Visa Inc. USA-Foster City»,
«terminalId»: «ABCD1234»
>,
«acquirerCountryCode»: «840»,
«acquiringBin»: «408999»,
«retrievalReferenceNumber»: «330000550000»,
«senderCurrencyCode»: «USD»,
«addressVerificationData»: <
«street»: «XYZ St»,
«postalCode»: «12345»
>,
«systemsTraceAuditNumber»: «451001»,
«businessApplicationId»: «AA»,
«senderPrimaryAccountNumber»: «4895142232120006»,
«foreignExchangeFeeTransaction»: «11.99»,
«senderCardExpiryDate»: «2015-10»
>

Response
<
«transmissionDateTime»: «2020-07-15T18:33:28.000Z»,
«approvalCode»: «98765X»,
«cpsAuthorizationCharacteristicsIndicator»: «3333»,
«transactionIdentifier»: 623422177635620,
«actionCode»: «00»,
«responseCode»: «5»
>

Response Header
Status Code: 200 OK
Server : nginx
Date : Wed, 15 Jul 2020 18:33:28 GMT
Content-Type : application/json;charset=UTF-8
Content-Length : 202
Connection : keep-alive
X-SERVED-BY : l55c014
X-CORRELATION-ID : 1594838008_500_923262086_l55c014_VDP_WS
X-APP-STATUS : 200
X-APP-STATUS : 200
X-Backside-Transport : OK OK,OK OK
X-Global-Transaction-ID : 1adcbd165f0f4bf8f2d78181
X-Frame-Options : SAMEORIGIN
X-XSS-Protection : 1; mode=block
X-Content-Type-Options : nosniff
Strict-Transport-Security : max-age=2592000;includeSubdomains
Cache-Control : no-cache, no-store, must-revalidate
Pragma : no-cache
Expires : -1
Content-Language : en-US

I was using the VDC Playground tool to test. It can be downloaded from your project asset page. Details can be found here: https://community.developer.visa.com/t5/Developer-Tools/How-to-test-and-troubleshoot-APIs-with-the-V.

Was your question answered? Don’t forget to click on «Accept as Solution» to help other devs find the answer to the same question.

Источник

curl-and-php

I am attempting to use curl within PHP to connect to a site which requires
HTTPS client authentication (over IPSec!). I have been provided with the
public (x509/PEM) keys for their server but I am apparently doing something
wrong in my connection attempts.

I keep getting the following in my connection tests:

* About to connect() to 199.4X.14X.12X port 443
* Trying 199.43.146.123. * connected
* Connected to 199.4X.14X.12X (199.4X.14X.12X) port 443
* unable to set private key file: ‘/opt/bin/site-dev.crt’ type PEM

* Closing connection #0
FATAL ERROR
On attempt the following error occured:
The return code was: 58

Once connected we’ll be able to send SOAP requests for various information.

My code looks like this:

// set url to use
curl_setopt($ch, CURLOPT_URL, $url);

// setup other curl options needed
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($ch, CURLOPT_CAINFO,
‘/usr/local/apache/conf/ssl.crt/ca-bundle.crt’);
curl_setopt($ch, CURLOPT_SSLCERT, getcwd() .’/site-dev.crt’);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_VERBOSE, 1); ########### debug
curl_setopt($ch, CURLOPT_MUTE, 1);
curl_setopt($ch, CURLOPT_NOPROGRESS, 0);
>
curl_setopt($ch, CURLOPT_ENCODING, ‘gzip’);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, FALSE);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_COOKIEJAR, ‘cookie.txt’);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);

$content = curl_exec($ch);
$error = curl_errno($ch);

if ($error > 0)
print «Error: $errorn»;
else
print «Success!n»;

I do realize of course it is asking for a private key, so is there a way to
get it to use the public key instead?

____________________________________________________________________
Dan Brown
danb_at_zu. com

Источник

cURL с сертификатами SSL завершается ошибкой: ошибка 58 не может установить файл закрытого ключа

Я пытаюсь подключиться к удаленному хосту с помощью cURL. Соединение требует использования сертификата и закрытого ключа, который защищен паролем. До сих пор я не смог с этим кодом ниже:

В результате я получаю ошибку 58 : unable to set private key file: ‘/home/. /domains/. /public_html/auth/key.pem’ type PEM ,

Вещи, которые я пробовал до сих пор:

• Проверьте, доступен ли файл ключа для чтения, как предложено здесь: Невозможно использовать libcurl для доступа к сайту, требующему аутентификации клиента . Попытка передать файл через openssl_private_key() дает мне ресурс, а не логическое. Так что это кажется хорошим.
• Переключите порядок содержимого в файле key.pem, как предлагается здесь: Невозможно использовать libcurl для доступа к сайту, требующему аутентификации клиента . Пока не повезло.
• Поиграл с некоторыми другими опциями, такими как SLL_VERIFY_PEER , SSL_VERIFY_HOST , SSL_CERTTYPE и другие варианты, которые казались тривиальными в отношении официальных PHP-документов. Пока не повезло.

Я почти уверен, что проблема кроется в моей конфигурации, но я не уверен, где искать.

Решение

Я исправил эту проблему. Я думаю, что из-за количества вопросов, касающихся этой проблемы и количества различных решений, другие получат пользу от решения. Вот оно:

Я использовал openssl Программа CLI для преобразования файла ключей .p12 в файл ключей .pem. Хитрость в том, как происходит преобразование.

Сначала я преобразовал это с этой командой, и у меня была проблема, как описано в вопросе:

openssl pkcs12 -in key.p12 -out key.pem -nodes -clcerts

В то время как команда ниже сделала настоящий трюк:

openssl pkcs12 -in key.p12 -out key.pem -clcerts

Для получения дополнительной информации см. Источник, который я использовал: https://community.qualys.com/docs/DOC-3273

Другие решения

На случай, если это будет полезно для других, ищущих эту проблему, я обнаружил, что CURLOPT_SSLCERT и CURLOPT_SSLKEY, похоже, не работают с относительными путями.

Источник

Inconsistency in cert/key params, OpenSSL ENGINE / PKCS#11 issues #974

Rather than continuing to pollute #964 I’ll open a new ticket. This command line works when curl is built against GnuTLS or a suitably fixed NSS:

It doesn’t work with OpenSSL, for a number of reasons.

One of the simple problems is that the curl command-line tool will automatically assume you want CURLOPT_SSLENGINE_DEFAULT if you pass —engine . This seems wrong, and it makes the SSL connection fail because you really don’t ever want that:

@nased0 I’m assuming this isn’t a problem for you because you’re using libcurl and not setting CURLOPT_SSLENGINE_DEFAULT ? I can’t understand why anyone would want that option, although it’s been present in curl(1) since the ENGINE support was first merged in commit af6c394. Can we just make the tool stop doing that?

Next we have to specify the ENGINE explicitly by adding —engine pkcs11 . We’ll want to automatically infer that from the ‘pkcs11:’ at the beginning of the command line. Which brings me to the CURLOPT_SSLCERTTYPE and CURLOPT_SSLKEYTYPE options.

I also need to pass —certtype ENG . OK, suboptimal but I can fix that (and let’s fix it to automatically determine PKCS#12 vs. PEM files while we’re at it, shall we? Just how much do we hate our users, to make them do that manually?).

So now maybe with —engine pkcs11 —cert-type ENG it’ll work.

Oh, that’s cute. We must really hate our users 🙂

We «assume» that the key identifier string (usually filename) is the same as the cert, but we don’t assume that it’s the same type? Really? OK, let’s tell it that the key is the same type as the cert.

This is getting surreal now. if I specify the key type you forget what the key was. Finally, if I spell everything out (and patch out the ENGINE_set_default() call as discussed above), it does actually work:

So. rants about hating users aside, what can we do about this? What part of this utter clusterf*ck do we need to preserve in the name of backward-compatibility, and what can we fix? 🙂

My suggestion would be to add a cert and key type of ‘AUTO’, which will be the default, and will work it out automatically. If it’s a filename, then look in the file to see if it’s PKCS#12 or PEM and act accordingly. And then only if your crypto library is insane enough to make you choose, rather than silently just doing the right thing with the filename you give it.

And if the string starts «pkcs11:» then it’s fairly obviously a PKCS#11 URI so treat it as such. Which means setting the engine to ‘pkcs11’ in the OpenSSL case, but other libraries should cope automatically. Although that’s partly because the NSS back end treats it as an NSS identifier even when the type is PEM . but OK, whatever.

It’s possible to fix this up in the tool, and have it inspect the —cert argument and manually set the type(s) accordingly. but I think it’s much better off in the library.

The text was updated successfully, but these errors were encountered:

Источник

I used curl to post xml payload to a web service by client certificate authentication.
It worked fine Linux(curl 7.15.5 (x86_64-redhat-linux-gnu))
But the same command with the same certificate failed in Windows(curl 7.23.1 (x86_64-pc-win32)).

$curl -k -s -o /dev/null  --connect-timeout 5 -w "ntime_total=%{time_total}nhttp_code=%{http_code}n" --cert cert2.pem: Pass123 --key cert2.pem    -d @data.xml https://server1/

curl: (58) unable to set private key file: 'cert2.pem' type PEM

This error could be due to invalid certificate password or invalid certificate format,  It seems the curl in windows is picker on certificate format than the curl in Linux.

In general, you can combine both certificate and key into one file by copy&paste the text in a text editor. But it seems the curl for Windows only accept the “formal format”, which has additional lines of “Bag Attributes” ( or maybe just different behaviour in different versions)

General  certificate
#cat cert1.pem

-----BEGIN CERTIFICATE-----
………………..

-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,D49E12E8D074DA59
…………….
-----END RSA PRIVATE KEY-----

”Formal” certificate with “Bag Attributes”
Bag Attributes

localKeyID: 92 47 FA AC C8 D4 94 D8 0C B0 D0 1D 9F D7 43 0B B5 D8 23 AD

subject=/C=AU/ST=NSW/L=Sydney/O=ORG1/CN=client1
issuer=/C=AU/ST=NSW/O=ORG1/CN=CA

-----BEGIN CERTIFICATE-----
………………….
-----END CERTIFICATE-----
Bag Attributes
localKeyID: 92 47 FA AC C8 D4 94 D8 0C B0 D0 1D 9F D7 43 0B B5 D8 23 AD

Key Attributes: <No Attributes>

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,6F6BA23BB03B5049

……………..
-----END RSA PRIVATE KEY-----

How to add the “Bag Attributes”?
#I found the “bag Attributes” can be added by converting PEM to pkcs12 format then convert back to PEM.

#Convert  from PEM to PKCS12

$openssl pkcs12 -export -in cert1.pem  -out cert1.pfx
#Convert back from  PKCS12 to PEM

$ openssl pkcs12 -in cert1.pfx  -out cert2.pem -clcerts
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
#It worked with the new certificate

C:tempcurlcurl -k -s -o /dev/null  --connect-timeout 5 -w "ntime_total=%{time_total}nhttp_code=%{http_code}n" --cert cert2.pem:Pass123  --key cert2.pem  -d @data.xml https://server1/

time_total=2.812
http_code=200

<?php
$wsdl       = 'https://domain.com/?wsdl';
$certFile   = getcwd() . '/auth/cert.pem';
$keyFile    = getcwd() . '/auth/key.pem';
$password   = 'pwd';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,           $wsdl);
curl_setopt($ch, CURLOPT_SSLCERT,       $certFile);
curl_setopt($ch, CURLOPT_SSLKEYPASSWD,  $password);
curl_setopt($ch, CURLOPT_SSLKEY,        $keyFile);
#curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);
#curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
#curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
$output = curl_exec($ch);

var_dump(curl_errno($ch));
var_dump(curl_error($ch));

Решение

Другие решения

Rather than continuing to pollute #964 I’ll open a new ticket. This command line works when curl is built against GnuTLS or a suitably fixed NSS:

curl -E pkcs11:manufacturer=piv_II;id=%01;pin-value=1234 $URL

It doesn’t work with OpenSSL, for a number of reasons.

One of the simple problems is that the curl command-line tool will automatically assume you want CURLOPT_SSLENGINE_DEFAULT if you pass --engine. This seems wrong, and it makes the SSL connection fail because you really don’t ever want that:

* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure
* Marked for [closure]: Failed HTTPS connection

@nased0 I’m assuming this isn’t a problem for you because you’re using libcurl and not setting CURLOPT_SSLENGINE_DEFAULT? I can’t understand why anyone would want that option, although it’s been present in curl(1) since the ENGINE support was first merged in commit af6c394. Can we just make the tool stop doing that?

Next we have to specify the ENGINE explicitly by adding --engine pkcs11. We’ll want to automatically infer that from the ‘pkcs11:’ at the beginning of the command line. Which brings me to the CURLOPT_SSLCERTTYPE and CURLOPT_SSLKEYTYPE options…

I also need to pass --certtype ENG. OK, suboptimal but I can fix that (and let’s fix it to automatically determine PKCS#12 vs. PEM files while we’re at it, shall we? Just how much do we hate our users, to make them do that manually?).

So now maybe with --engine pkcs11 --cert-type ENG it’ll work…

curl: (58) unable to set private key file: 'pkcs11:manufacturer=piv_II;id=%01;pin-value=1234' type PEM

Oh, that’s cute. We must really hate our users

We «assume» that the key identifier string (usually filename) is the same as the cert, but we don’t assume that it’s the same type? Really? OK, let’s tell it that the key is the same type as the cert…

curl  $URL --engine pkcs11 --cert-type ENG -E 'pkcs11:manufacturer=piv_II;id=%01;pin-value=1234'  --key-type ENG
No keys found.
PKCS11_get_private_key returned NULL
curl: (58) failed to load private key from crypto engine

This is getting surreal now… if I specify the key type you forget what the key was. Finally, if I spell everything out (and patch out the ENGINE_set_default() call as discussed above), it does actually work:

curl  -k https://localhost:4443/data.txt  --engine pkcs11 
  --cert-type ENG -E 'pkcs11:manufacturer=piv_II;id=%01;pin-value=1234' 
  --key-type ENG --key 'pkcs11:manufacturer=piv_II;id=%01;pin-value=1234'

So… rants about hating users aside, what can we do about this? What part of this utter clusterf*ck do we need to preserve in the name of backward-compatibility, and what can we fix?

My suggestion would be to add a cert and key type of ‘AUTO’, which will be the default, and will work it out automatically. If it’s a filename, then look in the file to see if it’s PKCS#12 or PEM and act accordingly. And then only if your crypto library is insane enough to make you choose, rather than silently just doing the right thing with the filename you give it.

And if the string starts «pkcs11:» then it’s fairly obviously a PKCS#11 URI so treat it as such. Which means setting the engine to ‘pkcs11’ in the OpenSSL case, but other libraries should cope automatically. Although that’s partly because the NSS back end treats it as an NSS identifier even when the type is PEM… but OK, whatever.

It’s possible to fix this up in the tool, and have it inspect the --cert argument and manually set the type(s) accordingly… but I think it’s much better off in the library.

Another long story cut short, but I saw this: —

curl: (58) unable to set private key file: ‘dave.pem’ type PEM

from my Ansible/Python code, whilst attempting to use a PEM certificate that I’d generated myself: —

Generate Private Key

Having munged the key and certificate into a single PEM file: —

cat key.pem cert.pem > dave.pem

I found that my Python code was then validating the private key within dave.pem : — 

cert_pkey.split(‘——BEGIN PRIVATE KEY——‘)

which meant that it was failing …

Simple solution, right ?

Yeah, I edited dave.pem to remove the characters RSA from the PEM file: —

Problem solved, right ?

NAH!!

My code, which uses cURL under the covers, then failed with: —

curl: (58) unable to set private key file: ‘dave.pem’ type PEM

This blog post: —

described how one can validate the private key and its certificate: —

which SHOULD return a MD5 checksum, but instead returned: —

Yeah, you guessed it, I broke my private key by removing RSA 

It was relatively easy to fix, it was all down to the way that I was generating my key and certificate. I switched to this: —

and, after munging the key and certificate: —

cat dave.key dave.crt > dave.pem

I ended up with a PEM file that I did NOT need to edit i.e. it contained the key (!) string: —

and, more importantly, it validated without problems: —

1c03038c6be240c22d759bfef58e9db2

and, even more importantly, my code works!!!

Moral of the story ? Don’t manually hack your keys, instead check the way that you’re generating them in the first place