I am generating a self signed certificate using openssl in Ubuntu. I want to use it for localhost rest server. But while verification, I am getting error : x509: certificate signed by unknown authority, can anyone please tell me how I can resolve this error?
Thanks!
Place your root certificate and intermediate (if you have one) in /usr/share/local/ca-certificates with the .crt extension.
Run:
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
In this case, curl is your friend:
curl -Iv https://localhost/path/to/api
Also you can run openssl s_client
openssl s_client localhost:443
Additionally, you can interrogate your certificate by providing your certificate:
openssl s_client -connect localhost:443 -CAfile /path/to/your/cert.pem
If you certificate does not match, you know. Possibly you are using the wrong certificate for your REST API or the certificate is not being installed, which you can verify by looking in /etc/ssl/certs directory on your system (if you are running Linux)
Place your .crt certificate to /usr/share/ca-certificates
Edit /etc/ca-certificates.conf and add your certificate name there.
(Look at update-ca-certificates man page for more information.)
Then run sudo update-ca-certificates
Works for me in Ubuntu 22
I've had an issue where connecting with curl to https://server failed with:
curl: (60) server certificate verification failed.
but initiating a connection with openssl s_client worked fine.
The problem was somehow related to the server side, but I do not understand what could cause curl to reject the connection while openssl s_client was ok. OpenSSL 1.0.2s-fips
Help ?
Bummer. it was not the chain but the actual cert that had expired.
Somehow openssl s_client did not catch that. Nor did I.
(openssl s_client -showcerts did show chain certs but not server cert)
I am running Windows Vista and am attempting to connect via https to upload a file in a multi part form but I am having some trouble with the local issuer certificate. I am just trying to figure out why this isnt working now, and go back to my cURL code later after this is worked out. Im running the command:
openssl s_client -connect connect_to_site.com:443
It gives me an digital certificate from VeriSign, Inc., but also shoots out an error:
Verify return code: 20 (unable to get local issuer certificate)
What is the local issuer certificate? Is that a certificate from my own computer? Is there a way around this? I have tried using -CAfile mozilla.pem file but still gives me same error.
I had the same problem and solved it by passing path to a directory where CA keys are stored. On Ubuntu it was:
openssl s_client -CApath /etc/ssl/certs/ -connect address.com:443
Solution:
You must explicitly add the parameter -CAfile your-ca-file.pem.
Note: I tried also param -CApath mentioned in another answers, but is does not works for me.
Explanation:
Error unable to get local issuer certificate means, that the openssl does not know your root CA cert.
Note: If you have web server with more domains, do not forget to add also -servername your.domain.net parameter. This parameter will "Set TLS extension servername in ClientHello". Without this parameter, the response will always contain the default SSL cert (not certificate, that match to your domain).
This error also happens if you're using a self-signed certificate with a keyUsage missing the value keyCertSign.
Is your server configured for client authentication? If so you need to pass the client certificate while connecting with the server.
I had the same problem on OSX OpenSSL 1.0.1i from Macports, and also had to specify CApath as a workaround (and as mentioned in the Ubuntu bug report, even an invalid CApath will make openssl look in the default directory).
Interestingly, connecting to the same server using PHP's openssl functions (as used in PHPMailer 5) worked fine.
put your CA & root certificate in /usr/share/ca-certificate or /usr/local/share/ca-certificate.
Then
dpkg-reconfigure ca-certificates
or even reinstall ca-certificate package with apt-get.
After doing this your certificate is collected into system's DB:
/etc/ssl/certs/ca-certificates.crt
Then everything should be fine.
With client authentication:
openssl s_client -cert ./client-cert.pem -key ./client-key.key -CApath /etc/ssl/certs/ -connect foo.example.com:443
Create the certificate chain file with the intermediate and root ca.
cat intermediate/certs/intermediate.cert.pem certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
chmod 444 intermediate/certs/ca-chain.cert.pem
Then verfify
openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
intermediate/certs/www.example.com.cert.pem
www.example.com.cert.pem: OK
Deploy the certific
I faced the same issue,
It got fixed after keeping issuer subject value in the certificate as it is as subject of issuer certificate.
so please check "issuer subject value in the certificate(cert.pem) == subject of issuer (CA.pem)"
openssl verify -CAfile CA.pem cert.pem
cert.pem: OK
I got this problem when my NGINX server did not have a complete certificate chain in the certificate file it was configured with.
My solution was to find a similar server and extract the certificates from that server with something like:
openssl s_client -showcerts -CAfile my_local_issuer_CA.cer -connect my.example.com:443 > output.txt
Then I added the ASCII armoured certificates from that 'output.txt' file (except the machine-certificate) to a copy of my machines certificate-file and pointed NGINX at that copied file instead and the error went away.
this error messages means that
CABundle is not given by (-CAfile ...)
OR
the CABundle file is not closed by a self-signed root certificate.
Don't worry. The connection to server will work even
you get theis message from openssl s_client ...
(assumed you dont take other mistake too)
I would update #user1462586 answer by doing the following:
I think it is more suitable to use update-ca-certificates command, included in the ca-certificates package than dpkg-reconfigure.
So basically, I would change its useful answer to this:
Retrieve the certificate (from this stackoverflow answer and write it in the right directory:
# let's say we call it my-own-cert.crt
openssl s_client -CApath /etc/ssl/certs/ -connect <hostname.domain.tld>:<port> 2>/dev/null </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /usr/share/ca-certificates/my-own-cert.crt
Repeat the operation if you need other certificates.
For example, if you need CA certs for ldaps/starttls with Active Directory, see here for how to process this + use openssl to convert it in pem/crt:
openssl x509 -inform der -in LdapSecure.cer -out my-own-ca.pem
#and copy it in the right directory...
cp my-own-ca.pem /usr/share/ca-certificates/my-own-ca.crt
Add this certificates to the /etc/ca-certificates.conf configuration file:
echo "my-own-cert.crt" >> /etc/ca-certificates.conf
echo "my-own-ca.crt" >> /etc/ca-certificates.conf
Update /etc/ssl/certs directory:
update-ca-certificate
Enjoy
Note that if you use private domain name machines, instead of legitimate public domain names, you may need to edit your /etc/hosts file to be able to have the corresponding FQDN.
This is due to SNI Certificate binding issue on the Vserver or server itself
I am working with an external company. Lets call them evilcorp.com. I want to use openssl to debug a two way SSL handshake.
https://evilcorp.com is setup to not require client authentication.
https://evilcorp.com/webservices is setup to require client authentication.
How can I specify this path in openssl. So basically this works:
openssl s_client -connect evilcorp.com:443
But this does not work and gives me gethostbyname failure
openssl s_client -connect evilcorp.com/webservices:443
How can I get this to work (if possible)
You have a very simple error in the address. Here's the fix:
"openssl s_client -connect evilcorp.com:443/webservice"
You had the 443 at the end - it needs to go directly after to the domain name.
I'm not sure if this can be done at all but if it can be done then you first have to use openssl to connect to the clients host and already specify the client certificates. Then inside the successful connection you need to speak HTTP to access the relevant page.
I.e. you first connect:
$ openssl s_client -connect host:port -cert cert.pem -key key.pem
... CONNECTED
... Verify return code...
---
And then access the URL using the HTTP protocol
GET /protected_page/ HTTP/1.0
Host: example.org
<empty line>
Note that the last line must be an empty line according to the HTTP protocol. It might also that you need to use the -crlf option in openssl to get the line ends correct in case you have a strict web server. If all goes right the server should now issue a renegotiation request to the client, i.e another TLS handshake is done.
I'm using Apache HttpClient 4.5.2 to make CloudKit Web API requests. When I send requests to the CloudKit endpoint URL (https://api.apple-cloudkit.com/[...]), I get the following error:
javax.net.ssl.SSLException: Certificate for <api.apple-cloudkit.com> doesn't match any of the subject alternative names: [*.icloud.com]
I'm no expert on SSL, but it looks like Apple is serving a certificate for api.apple-cloudkit.com that's only valid for *.icloud.com. Am I understanding that right?
Or if the certificate is correct, then why is HttpClient complaining?
It looks like the library you use or the underlying platform does not support Server Name Indication (SNI). Without SNI you get:
$ openssl s_client -connect api.apple-cloudkit.com:443 | openssl x509 -text
...
Subject: CN=*.icloud.com,
But when using SNI you get a different certificate:
$ openssl s_client -connect api.apple-cloudkit.com:443 \
-servername api.apple-cloudkit.com | openssl x509 -text
...
Subject: ...CN=cdn.apple-cloudkit.com
X509v3 Subject Alternative Name:
DNS:api.apple-cloudkit.com, DNS:cdn.apple-cloudkit.com
Older versions of the Apache HTTPClient library are known to have missing support for SNI so make sure you use a recent version.