I want to upload a Python package to a secured (HTTPS) Artifactory server from my machine using Twine.
First, using the following:
twine upload --verbose \
--repository-url https://URL/artifactory/api/pypi/PATH \
--username XX \
--password XX \
dist/*
I get the following error:
requests.exceptions.SSLError: HTTPSConnectionPool(host='URL', port=443): Max retries exceeded with url: /artifactory/api/pypi/PATH (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108)')))
After a big of digging, I found this little solution. So I downloaded the cert.pem file and provided it to my upload command with:
--cert ../../bin/cert.pem
Which still gives me the following error:
certificate verify failed: unable to get local issuer certificate
How can I solve this issue correctly (I would like NOT TO disable SSL check).
It appears to be an issue with the client in recognizing the certificate. Are you trying to execute the above mentioned task in a MacOS machine? If yes, installing Certificates.command should help resolving this issue.
How?
Go to the Applications folder in the system, select the appropriate Python installation directory and double click on Certificates.command file.
I should have searched a bit more. Here is the answer (for my self me in the future most likely).
You need a PEM file containing all the certificate chain (if applicable) of the server you want to contact. In my question, I downloaded only the end certificate, missing the root and intermediate one.
To achieve this, a manual option is to download all certificates from the browser (you can find plenty of examples on Internet on how to do that, like, for example, this one for Edge). You may find several nodes in the tree, download all of them.
After this is done, concatenate the certificates into one file, which would look like:
-----BEGIN CERTIFICATE-----
THE KEY
BLABLA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
THE OTHER KEY
BLABLA
-----END CERTIFICATE-----
If you had to download N certificates, you should have N sections in your unique file.
THen, pass that file to the command line:
--cert my_file_with_all_the_certificates
Related
I'm trying to have a server A communicate with a server B through HTTPS requests. Server B has a certificate that was issued to me by my employer, and connecting to it through both Safari and Chrome works without any issues.
However, when trying to send a request from A to B through Guzzle, I get the following error:
GuzzleHttp/Exception/RequestException with message 'cURL error 60: SSL certificate problem:
unable to get local issuer certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)'
I've tried setting the cert file as a parameter ( [verify => '/path/to/cert.pem'] ), but, first of all, I only had .crt, .csr and .key files; I tried making a .pem file through these instructions I found somewhere else:
(optional) Remove the password from the Private Key by following the steps listed below:
openssl rsa -in server.key -out nopassword.key
Note: Enter the pass phrase of the Private Key.
Combine the private key, public certificate and any 3rd party intermediate certificate files:
cat nopassword.key > server.pem
cat server.crt >> server.pem
Note: Repeat this step as needed for third-party certificate chain files, bundles, etc:
cat intermediate.crt >> server.pem
This didn't work – the error's the same. The request works with 'verify' set to false, but that's obviously not an option for production.
Certificates are not something I usually work with, so I'm having a lot of trouble just figuring out where the issue might lie, let alone fix it. Any help would be much appreciated.
Edit
I've also tried the solutions suggested in Guzzle Curl Error 60 SSL unable to get local issuer to no avail.
This was happening because the only certificate I had configured on server B was the End User certificate.
I'm new to this, so my explanation will probably be flawed, but from my understanding End User certificates link back to a trusted Certificate Authority (CA) certificate, with zero or more intermediate certificates in-between. Browsers can figure out this certificate chain, and download the required certificates that are missing; cURL does not.
Therefore, the solution was configuring Server B with the missing certificates. How to do this is a whole different issue, so I won't go into it in this answer.
I am using the curl terminal and while issuing the following command :-
curl --anyauth --user admin:admin "https://localhost:8000/LATEST/search?q=caesar"
I am getting below alert :-
curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
Please suggest. I have installed curl in Windows and also downloaded the .pem file and placed it in the same folder.
If your server has a self-signed cert, then by default curl doesn't know that it can trust that the server is who it says it is, and doesn't want to talk.
You can either:
import the cert into your trust store (best and most secure)
apply the -k or --insecure switch to ignore and continue. This may be fine for local development.
use a real cert, signed by a trusted CA
For local dev and a quick solution, run this line
set_config( config( ssl_verifypeer = 0L ) )
before
httr::GET(....)
but as suggested it's still preferable to use a real cert.
My registrar, gandi, gave me an intermediate cert to install, so I have 3 files:
Private key file (server.key)
Certificate file (mycert.crt)
Intermediate cert (GandiSomething.pem)
I'm using the SSL Beta service on heroku. The heroku CLI heroku _certs:add, takes exactly two arguments, CRT and KEY. how do I install the intermediate cert?
Paul is right, you can combine certificates:
cat ssl.crt middle.crt root.crt > all.crt
Be assured that newlines at the end of cert files!
And upload it to Heroku (use add if you haven't SSL Endpoint yet):
heroku certs:update --app $YOUR_APP --confirm $YOUR_APP all.crt private.key
But there are some tricks you haven't forget:
Update your DNS CNAME record. Change target from <app>.herokuapp.com to secure <domain>.herokudns.com (be careful, if you have *.your.domain record it can catch requests and forward it to another server)
Check the cert chain works right: SSL Checker
Flush local DNS: Flush DNS tips (antivirus also can patch and cache you connections)
Restart your browser (to flush browser's cache too)
Check your app with browser by https:// connection
The solution here is to combine the intermediate cert and the generated cert into one file, as described here. Because that link is shady, here's how the cert file should look once combined:
-----BEGIN CERTIFICATE-----
MIIEKjCCAxKgAwIBAgIEOGPe+DANBgkqhkiG9w0BAQUFADCBtDEUMBIGA1UEChML
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
wfsm5p9GJKaxB825DOgNghYAHZaS/KYIoA==
-----END CERTIFICATE-----
Then, this command will work:
heroku _certs:add --app name-of-my-app file-with-combined-certs.crt myserver.key
Just pass it in as an argument. Put the intermediate in the middle, it takes it as another argument. Then check heroku certs and report back if it doesn't work.
I have been trying to understand why I cannot access these links from my webbrowser
or even when using:
wget https://secure.cprod.homeps3.online.scee.com/CommercePoints/MarketPlace/E/ThreadsCP.xml
error
# wget https://secure.cprod.homeps3.online.scee.com/CommercePoints/MarketPlace/E/ThreadsCP.xml
--2012-01-28 01:23:34-- https://secure.cprod.homeps3.online.scee.com/CommercePoints/MarketPlace/E/ThreadsCP.xml
Resolving secure.cprod.homeps3.online.scee.com... 217.18.28.81
Connecting to
secure.cprod.homeps3.online.scee.com|217.18.28.81|:443... connected.
OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure Unable to establish SSL connection.
These links are normally requested from a client named Playstation Home.
How can we access these links without being on the client?
I have been doing a lot of reading about SSL lately and unfortunately I have tried to install the certs from the browser even have the certs and trying many different things to get access to the links, nothing has worked so far.
I would like to access them to get the latest content from the stores when the client is offline so I can see what I can shop around for when I use the client.
Is it impossible to get access to this link above? Should I stop looking for answers?
You need two certs: 1) the cert file containing the server certificate with chain; 2) the client cert. Then you can try using "curl" command:
$curl --cacert server_cert_with_chain.pem --cert client_cert.pem "https://secure.cprod.homeps3.online.scee.com/CommercePoints/MarketPlace/E/ThreadsCP.xml"
The server cert chain file can be exported from browser: Firefox -> Preferences -> Advanced -> Encryption -> View Certificate -> Servers; select the cert under "Sony"; click "Export..."; select Format of "X.509 Certificate with Chain (PKCS#7)".
This exported file is in DER format. Use this command to convert it to PEM format:
$openssl pkcs7 -inform DER -in exported_server_cert -print_certs -out server_cert_with_chain.pem
I am trying to verify an SSL connection to Experian in Ubuntu 10.10 with OpenSSL client.
openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443
The problem is that the connection closes with a Verify return code: 21 (unable to verify the first certificate).
I've checked the certificate list, and the Certificate used to sign Experian (VeriSign Class 3 Secure Server CA - G3) is included in the list.
/etc/ssl/certs/ca-certificates.crt
Yet I don't know why it is not able to verify the first certificate.
The entire response could be seen here:
https://gist.github.com/1248790
The first error message is telling you more about the problem:
verify error:num=20:unable to get local issuer certificate
The issuing certificate authority of the end entity server certificate is
VeriSign Class 3 Secure Server CA - G3
Look closely in your CA file - you will not find this certificate since it is an intermediary CA - what you found was a similar-named G3 Public Primary CA of VeriSign.
But why does the other connection succeed, but this one doesn't? The problem is a misconfiguration of the servers (see for yourself using the -debug option). The "good" server sends the entire certificate chain during the handshake, therefore providing you with the necessary intermediate certificates.
But the server that is failing sends you only the end entity certificate, and OpenSSL is not capable of downloading the missing intermediate certificate "on the fly" (which would be possible by interpreting the Authority Information Access extension). Therefore your attempt fails using s_client but it would succeed nevertheless if you browse to the same URL using e.g. FireFox (which does support the "certificate discovery" feature).
Your options to solve the problem are either fixing this on the server side by making the server send the entire chain, too, or by passing the missing intermediate certificate to OpenSSL as a client-side parameter.
Adding additional information to emboss's answer.
To put it simply, there is an incorrect cert in your certificate chain.
For example, your certificate authority will have most likely given you 3 files.
your_domain_name.crt
DigiCertCA.crt # (Or whatever the name of your certificate authority is)
TrustedRoot.crt
You most likely combined all of these files into one bundle.
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: DigiCertCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----
If you create the bundle, but use an old, or an incorrect version of your Intermediate Cert (DigiCertCA.crt in my example), you will get the exact symptoms you are describing.
SSL connections appear to work from browser
SSL connections fail from other clients
Curl fails with error: "curl: (60) SSL certificate : unable to get local issuer certificate"
openssl s_client -connect gives error "verify error:num=20:unable to get local issuer certificate"
Redownload all certs from your certificate authority and make a fresh bundle.
I came across the same issue installing my signed certificate on an Amazon Elastic Load Balancer instance.
All seemed find via a browser (Chrome) but accessing the site via my java client produced the exception javax.net.ssl.SSLPeerUnverifiedException
What I had not done was provide a "certificate chain" file when installing my certificate on my ELB instance (see https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate)
We were only sent our signed public key from the signing authority so I had to create my own certificate chain file. Using my browser's certificate viewer panel I exported each certificate in the signing chain. (The order of the certificate chain in important, see https://forums.aws.amazon.com/message.jspa?messageID=222086)
Here is what you can do:-
Exim SSL certificates
By default, the /etc/exim.conf will use the cert/key files:
/etc/exim.cert
/etc/exim.key
so if you're wondering where to set your files, that's where.
They're controlled by the exim.conf's options:
tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key
Intermediate Certificates
If you have a CA Root certificate (ca bundle, chain, etc.) you'll add the contents of your CA into the exim.cert, after your actual certificate.
Probably a good idea to make sure you have a copy of everything elsewhere in case you make an error.
Dovecot and ProFtpd should also read it correctly, so dovecot no longer needs the ssl_ca option.
So for both cases, there is no need to make any changes to either the exim.conf or dovecot.conf(/etc/dovecot/conf/ssl.conf)
If you are using MacOS use:
sudo cp /usr/local/etc/openssl/cert.pem /etc/ssl/certs
after this Trust anchor not found error disappears
For those using zerossl.com certificates, drag and drop all certificates (as is) to their respective folders.
Cut and pasting text into existing files, may cause utf8 issues - depending upon OS, format and character spacings.