Download Ca Certificate From Website Curl _HOT_
Roseanna Diomede
I had the same problem - I was fetching a page from my own site, which was served over HTTPS, but curl was giving the same "SSL certificate problem" message. I worked around it by adding a -k flag to the call to allow insecure connections.
Edit: I discovered the root of the problem. I was using an SSL certificate (from StartSSL, but I don't think that matters much) and hadn't set up the intermediate certificate properly. If you're having the same problem as user1270392 above, it's probably a good idea to test your SSL cert and fix any issues with it before resorting to the curl -k fix.
You need to provide the entire certificate chain to curl, since curl no longer ships with any CA certs. Since the cacert option can only use one file, you need to concat the full chain info into 1 file
For me, I just wanted to test a website that had an automatic http->https redirect. I think I had some certs installed already, so this alone works for me on Ubuntu 16.04 running curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
If libcurl was built with Schannel or Secure Transport support (the native SSL libraries included in Windows and Mac OS X), then this does not apply to you. Scroll down for details on how the OS-native engines handle SSL certificates. If you are not sure, then run "curl -V" and read the results. If the version string says Schannel in it, then it was built with Schannel support.
This system is about trust. In your local CA certificate store you have certs from trusted Certificate Authorities that you then can use to verify that the server certificates you see are valid. They are signed by one of the certificate authorities you trust.
If the remote server uses a self-signed certificate, if you do not install a CA cert store, if the server uses a certificate signed by a CA that is not included in the store you use or if the remote host is an impostor impersonating your favorite site, and you want to transfer files from this server, do one of the following:
Get a CA certificate that can verify the remote server and use the proper option to point out this CA cert for verification when connecting. For libcurl hackers: curl_easy_setopt(curl, CURLOPT_CAINFO, cacert);
If libcurl was built with Schannel (Microsoft's native TLS engine) or Secure Transport (Apple's native TLS engine) support, then libcurl will still perform peer certificate verification, but instead of using a CA cert bundle, it will use the certificates that are built into the OS. These are the same certificates that appear in the Internet Options control panel (under Windows) or Keychain Access application (under OS X). Any custom security rules for certificates will be honored.
Since version 7.52.0, curl can do HTTPS to the proxy separately from the connection to the server. This TLS connection is handled separately from the server connection so instead of --insecure and --cacert to control the certificate verification, you use --proxy-insecure and --proxy-cacert. With these options, you make sure that the TLS connection and the trust of the proxy can be kept totally separate from the TLS connection to the server.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
Your browsers work because they cache CA certificates. If you've navigated to a correctly configured website at some point in the past, whose certificate was issued by the same CA as your server's certificate, it will be cached by the browser. When you subsequently visit your incorrectly configured site, your browser will use the CA certificates in its cache to build the chain. To you, it seems like everything is fine, although behind the scenes, the server is mis-configured.
In addition to the above, IE/Edge and Chrome (as they share the same crypto stack) will use an extension within certificates called the AuthorityInformationAccess. This has a caIssuer option which provides a URL from which the end-entity certificate's CA certificate can be downloaded. Therefore, even if one of these browsers hasn't cached the missing certificates from previous browsing, it can fetch it if required. Note that Firefox doesn't do this, which is why sometimes Firefox can show certificate errors when IE/Edge and Chrome seem to work.
Command-line utilities such as curl and wget can use these CA certificates to validate server certificates. Many tools provided with Red Hat Enterprise Linux also use these certificates, including for interactions with Red Hat support (redhat-support-tool), Red Hat OpenShift clusters (oc), and Red Hat Satellite 6 servers (hammer). Many other interactions with server API interfaces also use SSL/TLS and should validate the certificates offered.
it feels like already searched through the whole internet, but I can't find a solution that is working.
My scenario is this:
I connect to a network via VPN.
In the network, there is a website that uses a self-signed certificate.
I want to trust this specific certificate in order to avoid annoying browser warnings (I'm using Chrome/Brave).
This stores the certificate with a bunch of meta data in a file in /etc/ca-certificates/trust-source/. This also leads to trust list showing me the certificate that I previously added (the category is other-entry however, unlike the other entries).
I thought this would be enough, so I restarted my browser and entered the URL. My browser however, tells me the connection is not secure (self-signed certificate). So double checked with curl, same result:
Good news, I solved it! Also thanks to qinohe's answers.
I realized I had to import a CA certificate instead of the "non-CA" certificate (maybe there is a special term for this).
I then opened up the details of the "non-CA" certificate in my browser. The details view spit out a bunch of URLs, one of which referred to a crt-file.
I copied the URL and downloaded the CA crt file via curl:
curl: (60) SSL certificate problem: self signed certificate in certificate chainMore details here: performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.curl: (3) malformedcurl: (3) malformedcurl: (3) malformedcurl: (3) malformed
With the error message you provided: ("SSL certificate problem: self signed certificate in certificate chain"), what curl is saying is: I've followed the chain of certificates back to a self-signed certificate, which I do not trust.
The server, in my discussion above it is example.com, is presenting a certificate which is not signed by a trusted CA, or any CA that can be chained back to a trusted CA listed in the client's trust store. curl is rightly saying "I don't trust this cert."
The government of the country I live in has blocked wikipedia.org. Out of curiosity, I was messing around to maybe ascertain which methods were used etc. After changing my default DNS resolver to Cloudflare (1.1.1.1), I am now able to visit the address using CLI browser lynx. However, I am not able to visit the site from my browser (Safari), nor cURL. The output of command curl -vv gives:
Below is a simple curl command I ran from the terminal application on my MacBook. This one requests the homepage of Fastly.com and displays the full HTML. A caution that this is a noisy output that we will clean up later.
The current use of shows the URL being requested. Whichever hostname is used within the URL (e.g www.fastly.com) will be the value curl uses to request and verify the SSL certificate name. This is important in order to validate that TLS is working the way you expect it to, and that your site is secure with the certificate you expect. See the example below:
If you completed all of the installation steps but are still having an issue, you should generate a new CSR from your server (see the CSR creation instructions) and then reissue the certificate in your DigiCert account by logging in, clicking the order number, and then clicking the reissue link.
To resolve this problem, install the intermediate certificate (or chain certificate) file to the server that hosts your website. To do that, log into your DigiCert Management Console, click the order number, and then select the certificate download link. This file should be named DigiCertCA.crt. Then follow your server-specific installation instructions to install the intermediate certificate file.
Internet Explorer 7: "The security certificate presented by this website was not issued by a trusted certificate authority. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server."
It looks like our CA certificate bundle is getting a bit old. You can download a more up-to-date one here and put it somewhere in your files storage. Then you can use the --cacert option to curl to point to that file. Alternatively, you can use the -k option.
Hi, I'm facing the same problem with server certificate verification failing using curl. I used the latest .pem from and specified the path to the certificate using --cacert option but still does not work. I also tried including the -U option but still not working. It only works with the -k option but I would prefer other alternatives. Any update on this topic?
df19127ead