Download Certificate From Website Curl

3 views
Skip to first unread message

Maria Haq

unread,
Jan 8, 2024, 10:42:55 AM1/8/24
to coidenmaigran

I need to download an SSL certificate of a remote server (not HTTPS, but the SSL handshake should be the same as Google Chrome / IE / wget and curl all give certificate check fail errors) and add the certificate as trusted in my laptops Windows' certificate store since I am not able to get my IT guys to give me the CA cert.

A quick method to get the certificate pulled and downloaded would be to run the following command which pipes the output from the -showcerts to the x509 ssl command which just strips everything extraneous off. For example:

download certificate from website curl


Download Zip https://7granad-vcheizu.blogspot.com/?kgd=2x5qch



curl can be told to use a separate stand-alone file as CA store, and conveniently enough curl provides an updated one on the curl web site. That one is automatically converted from the one Mozilla provides for Firefox, updated daily. It also provides a little backlog so the ten most recent CA stores are available.

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.

I am trying to renew certificate but get timeout error. I checked availability of ports 80 and 443 from Port Checker - Check Open Ports Online, and website seems reachable in Website Uptime Test: Check Website Status Uptrends. But http-01 challenge is failing. During the challenge I tried curl -known/acme-challenge/4cYht4W9exJbmOib2GwxKnUpPV2EYxrpyB8ZdMSGLvQ from another server (outside of this domain) and I can read the file. I currently disabled https redirection to test if this is the issue but it seems not.

Thank you @peterparker . But i am getting the same error. Seems earlier the issue (issue in the thread you pointed) was HTTP 404. but now it is a certificate expiration issue. I am not sure if this is an issue in curl or from the website.
image1138462 69.1 KB

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:

Due to the Azure AD environment, I was receiving the above cURL error.
From the PHP website I found:
cURL error 60: SSL certificate problem: unable to get local issuer certificate
This problem can occur when developing locally on windows. I am using windows 10 (x64)
In order to fix the error, I downloaded cacert.pem from
Set the following value for in php.ini
curl.cainfo = "C: \ php-8.0.7 \ extras \ ssl \ cacert.pem"

When a server is configured to use SSL/TLS so that packets exchanged between the client and server are encrypted, the client will need to obtain the certificate from the server. For example, the following diagram illustrates how a client would obtain the certificate from an HTTPS web server.

If the -k or --insecure option are not used, cURL will only get certificates that have been issued by a trusted certificate authority (CA). If you want to get certificates from both a trusted and untrusted certificate authority, use the -k or --insecure option.

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:

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?

This is often due to PHP cURL, the service Deskpro uses for external websites, having outdated certificates for https requests. As it does not recognise the newer certificates, it will refuse to connect to these external websites, which can block some Deskpro services from running correctly.

This can be fixed easily by manually updating the list of trusted root certificates to include the newer LetsEncrypt ISRG Root X1 root certificate. We recommend using the curl.se CA Bundle, as this is regularly extracted from the Firefox browser, which is maintained by Mozilla, and is formatted in a way which cURL expects.

At this point, I strongly believe that there is a HTTP/TLS proxy in front of you, which intercepts the traffic, and thus presents the wrong CA certificate. We can verify that together by analysing your output from the commands above.

35fe9a5643
Reply all
Reply to author
Forward
0 new messages