Certificate issues with centOS7 with curl - ssl

I have an issue when using certificate when using curl. I'm running centOS7. We managed to get the curl going in other places, but not our dev machine:
What we are trying to do:
sudo curl -X 'GET' 'https://webpage/document' --cert '/localization.crt.pem' --key '/localization.key.pem' -H 'accept: */*' -k
Im getting this error:
curl: (58) SSL peer cannot verify your certificate.
What I tried to do?(from centOS documentation)
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide_common_criteria_edition/importing_certificate_into_nssdb
# PKICertImport -d . -n "client name" -t ",," -a -i certificate.crt.pem -u C
after echo $? we get a 0, so i think it is installed properly?
Any idea on whats wrong would be great.

I have run into this recently on our linux environments. I've found that this tends to happen if you have an SSL Certificate issued that also includes a chain certificate. If that chain is not also configured on your server OpenSSL considers the certificate invalid.
I would test this using this command:
openssl s_client -showcerts -verify 5 -connect website.com:443
If you see a block like this that means you are missing the certificate chain in your server configuration:
---
SSL handshake has read 2162 bytes and written 401 bytes
Verification error: unable to verify the first certificate
---
Windows fills in the gaps and doesn't mind this type of configuration, but openssl is very particular.

I managed to solve the issue. Recompiled curl with openSSL with following tutorial:
Install curl with openssl
Works like a charm :)

Related

API Python connection error occurrence, [SSL socket programming inquiry]

An SSL handshake error occurred in the process of making an API call with Python.
The reason for the SSL handshake error is that information such as client certificate, CA certificate, and client private key should be used as options.
Query curl -k --tlsv1.2 --cacert ./ca-chain.crt --cert ./client.crt --key ./client.key -H
You should have the above settings.
I found the tlsv1.2 part at the beginning through an internet search,
import ssl
I learned that I just need to add the syntax context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2) .
Then cacert ./ca-chain.crt --cert ./client.crt --key ./client.key did not know how to implement this part in Python code, so I asked a question.
The client certificate, CA certificate, and client private key are in the state that I extracted and kept with openssl.
Query: curl -k --tlsv1.2 --cacert ./ca-chain.crt --cert ./client.crt --key ./client.key -H I would like to know how to implement this in python code.
Thanks for reading this long post.
Then cacert ./ca-chain.crt --cert ./client.crt --key ./client.key did not know how to implement this part in Python code, so I asked a question.
ctx.load_verify_locations('./ca-chain.crt')
ctx.load_cert_chain('./client.crt', './client.key')
For more see the documentation.

cURL a local GO server using a self signed certificate

So i have a simple GO server running on port 8080 using a self-signed certificate that i created with the following command:
openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -out local.crt -keyout local.key
When creating it i set the fields to these values:
As you can see i skipped everything but the fully qualified host name which i set to go-auth
I started my go server using the local.key and local.crt files successfully.
I tried cURLing it like:
➜ certs git:(master) ✗ curl --proxy-cacert local.crt https://go-auth/
curl: (6) Could not resolve host: go-auth
➜ certs git:(master) ✗ curl --proxy-cacert local.crt https://localhost:8080/
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
After that i tried to get the certs from the running server and saving it to the cacert.pem file and tried again:
➜ certs git:(master) ✗ echo quit | openssl s_client -showcerts -servername go-auth -connect localhost:8080 > cacert.pem
depth=0 CN = go-auth
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = go-auth
verify return:1
DONE
➜ certs git:(master) ✗ curl --cacert cacert.pem https://go-auth/
curl: (6) Could not resolve host: go-auth
➜ certs git:(master) ✗ curl --proxy-cacert cacert.pem https://go-auth/
curl: (6) Could not resolve host: go-auth
At this point i don't know, i was trying to follow the answer to this question: Use self signed certificate with cURL? but did not get the desired result.
You can use the -k parameter in order to skip the certificate validation.
Your command have to be similar to the following one:
curl -vk https://localhost:8080/
-v enable some debug information
-k disable the certificate validation
If you want to enable the certificate validation, you have two way:
Add and trust the certificate to your current CA list
By this way, you are going to "accept" your self signed certificate as a valid one, and you will be able to call the service (from your machine, obviously) using any type of HTTP client (Java, Go, cURL etc etc).
Use the --cacert parameter of the cURL command in order to specify the path related to the certificate to use in order to authenticate to the service.

using mosquitto_sub with --insecure

Right now I have to do an initial test of a mqtt broker (ssl).
However right now I don't have the valid truststore certificates, however I would like to test the basic connectivity, ignoring SSL errors regarding hostname verification, certificate validation etc.
Unfortunately I am not successful, even with a broker I know it's working.
What I'm doing:
mosquitto_sub -h the_host -p 8883 -t '#' -v -u myUser -P myPass --insecure -d --capath /etc/ssl/certs
According to the manpage I just use the --capath to identify it's a TLS connection, well knowing that the necessary root certificate is not available here.
What I get is this:
Client mosqsub|11262-csbox sending CONNECT
Error: A TLS error occurred.
Any idea what I'm doing wrong?
Using --insecure just disables the verification of the hostname in the certificate presented by the broker. It does not remove the need to have a copy of the CA certificate that signed the brokers certificate.
So if /etc/ssl/certs doesn't contain a matching CA certificate then the connection will fail.
If needed you should be able to use something like openssl s_client to download the certificate chain directly from the broker, you can then point to that file with the --cafile option instead of the --capath option.

Using curl with certificate that has no password

I have my own CA and client certificate that I have been using successfully with cURL using the normal format:
curl --cacert /etc/myca.crt --cert /etc/myclient.pem:mypassword --cert-type PEM --get https://myhost.com
Now, for reasons outside the scope of this question, I have the same client certificate but the password has been removed using openssl. Using openssl I have verified that the new certificate is correct and I can use it to make SSL connections using applications other than cURL, but I cannot get it to work with cURL.
If I don't enter a password:
curl --cacert /etc/myca.crt --cert /etc/myclient.pem --cert-type PEM --get https://example.com
I get an error saying "curl: (58) unable to use client certificate (no key found or wrong pass phrase?)"
I have also tried:
curl --cacert /etc/myca.crt --cert /etc/myclient.pem: --cert-type PEM --get https://example.com
but I get the same error.
I am making the call to cURL from within a Perl script, so I need to find a way that will not prompt me for the password. I am using cURL 7.15.5 on RHEL 5.
Thank you.
You can make use of the --pass switch:
--pass <phrase> (SSL/SSH) Passphrase for the private key
To pass an empty passphrase you can use:
--pass ''

Use self signed certificate with cURL?

I have a flask application running using a self signed certificate. I'm able to send in a curl request using:
curl -v -k -H "Content-Type: application/json" -d '{"data":"value1","key":"value2"}' https://<server_ip>:<port>
The verbose logs show that everything went alright.
I wanted to avoid using the -k (--insecure) option and instead specify a .pem file that curl could use. Looking at the curl man page I found that you could do this using the --cert option.
So I created a .pem file using this:
openssl rsa -in server.key -text > private.pem
CURL throws me this error when using the private.pem file:
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
Any suggestions? - or is this only possible with a properly signed certificate?
Tnx
This is just another version of this question: Using openssl to get the certificate from a server
Or put more bluntly:
Using curl --cert is wrong, it is for client certificates.
First, get the the certs your server is using:
$ echo quit | openssl s_client -showcerts -servername server -connect server:443 > cacert.pem
(-servername is necessary for SNI so that you get the right virtual server's certificate back)
Then make your curl command line use that set to verify the server in subsequent operations:
$ curl --cacert cacert.pem https://server/ [and the rest]
special teaser
Starting with curl 7.88.0 (to be shipped in February 2023), curl can save the certificates itself with the new %{certs} variable for the -w option. Blogged about here.
To make request from https server through curl. I make use of below steps
Step1: Generate self signed certificate with below code at root of the project you want to make use of it.openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -nodes
Step2: Fill the prompt with required details but when you get to Common name input localhost e.g Common Name (eg, fully qualified host name) []:localhost
step3: When your openssl cert.pem & key.pem has being generated startup your server then in another terminal or command line run curl --cacert cert.pem https://localhost:443
Note: I use port 443 which is the default https port, you can make use of another port then make sure cert.pem file path is well referenced.