Issue: users can't log into mobile app due to "unable to contact server"
debugging message: "TypeError: Network request failed"
Attempted fixes: restarted server, verified that db is running and nothing has changed, restarted VM that server is running on, I checked the api using postman. When I ran a simple POST request I got the following message:
There was an error connecting to
https://app.something.com/api/Accounts/5076/sometest?filter%5Bwhere%5D%xxxxx%5D=null&access_token=mwVfUBNxxxxxxx5x4A4Y5DktKnTZXeL6CB34MoP.
One of the suggestions I was given was:
Self-signed SSL certificates are being blocked: Fix this by turning
off 'SSL certificate verification' in Settings > General
As soon as I followed this step, I was able to make the POST request and everything seemed to work fine. I'm completely new to this type of error. Allso, I did not set up this app/db/certificates. So, other than unblocking self-signed SSL certificates(which seems like a really bad idea), I'm not sure how to proceed. What are my options?
here's what the result of examining the certificate:
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0 poll
errornotBefore=Jan 28 11:54:38 2019 GMT
notAfter=Apr 28 11:54:38 2019 GMT
Either, purchase a signed certificate from a CA if you plan to expose this to the public.
Or the free option is to use Let's Encrypt, with this service, you are issues free certificates, however they expire in a relatively short period of time; most of the time however you can run an agent which will automatically rotate the certificates before they expire.
The third option is to install the CA certificate that was used to self sign this, into to your browser. i.e., like a large company might do.
edit
Seems like it might instead be an expired certificate? Check when it expires with this:
openssl s_client -showcerts -servername www.stackoverflow.com -connect www.stackoverflow.com:443 </dev/null | openssl x509 -noout -dates
change both instances of stackoverflow you your domain
Related
I am trying to connect to a webserver from my CentOS but I got an error regarding the certificate.
curl https://mywebsite ends with error 60 : Peer's certificate issuer is not recognized.
I am not able to add my CA certificate issuer.crt to the ca-bundle.crt.
Looking at /etc/pki/tls/certs/ca-bundle.crt.
My website certificate issuer is missing, that's why i got an error.
Verifying my CA_issuer_crt with curl --cacert /path/to/my/CA_issuer.crt https://mywebsite
Curl is successful.
So, trying to add my CA_issuer.crt to the ca-bundle.crt
I put my CA_issuer.crt to /etc/pki/ca-trust/source/anchors/CA_issuer.crt
running update-ca-certificate
Tried the followings
update-ca-certificate enable update-ca-certificate force enable update-ca-certificate extract
My /etc/pki/tls/certs/ca-bundle.crt seems updated (the last modified date is right now) but my CA certificate is still missing in the file + my curl test is still KO.
My certificate is an authority CA certificate is X509v3 Basic Constraits: CA:TRUE
openssl verify my CA_issuer.crt gives me an error.
18 at 0 depth lookup:self signed certificate OK
This CA certificate is deployed on several servers without issue.
I only have a couple of servers with this issue.
Any help is welcome to find a solution.
Thank you.
My application uses the Close API (https://developer.close.com/) to store user data. Our testing environment is now getting SSL errors when trying to write to it:
Faraday::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (certificate has expired))
What could the cause be? My first assumption reading the error message is that the Close certificates might have expired. But that seems unlikely - the service is generally well-maintained, and we are not having any issues in production.
The next thing I considered was that perhaps the certificate store on our server is out of date. That would not surprise me much, because the server is running Ubuntu 14, and other people are experiencing problems there. But we have multiple machines with the same configuration, and only one of them is giving us trouble. Is it possible this is the root cause?
To reproduce:
$ openssl s_client -CApath /dev/null -showcerts -connect api.close.com:443 -servername api.close.com
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
The problem turned out to be the recent deprecation of the DST root certificate. An old root certificate (DST) was deprecated on Sep 30, and the modern version (ISRG) is now expected.
The testing server still had the DST and ISRG certificates installed, whereas all the other machines only had ISRG. I assume that something about this particular API was looking preferentially for the DST certificate and ignoring ISRG unless it was the only one.
To solve: Remove DST cert from /usr/share/ca-certificates/mozilla and leave ISRG one there - try the openssl command above, now it works.
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.
One thing I could not find. I've just received a Comodo ssl certificate (.crt file and a key) from a client to install on the webserver. I did not receive an Intermediate though. The certificate CN is:
Extended Validation Secure Server CA
and i did find this Intermediate on Comodo website:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/931/91/intermediate-2-comodo-ev-secure-server-ca
How can I check whether this particular certificate is validated by this Intermediate?
I was trying
openssl verify -verbose -purpose sslserver -CAfile comodoextendedvalidationsecureserverca.crt my_certificate.crt
but got this error:
error 20 at 0 depth lookup:unable to get local issuer certificate
Which I would expect if the validation fails. But surprisingly I got similar error (error 2 at 1 depth lookup:unable to get issuer certificate) while trying this command on a certificate/Intermediate pair I'm sure is correct.
I want to make sure, I'm out of options of finding a proper Intermediate, before i start nagging my client.
As Patrick suggested:
openssl verify -purpose sslserver -untrusted <Intermediate_file.crt> <cerificate_file.crt>
Is a good way to go. Thanks
I have an application running on Centos7 that needs to connect to a remote host over HTTPS. However, it is unable to verify the certificate and fails. Also, if I try to download a file from the server using wget, I get the below error:
[root#foo:~]# wget https://10.65.127.9/index.html
--2017-05-22 09:03:01-- https://10.65.127.9/index.html
Connecting to 10.65.127.9:443... connected.
ERROR: cannot verify 10.65.127.9's certificate, issued by ‘/CN=us6877vnxe7827’:
Unable to locally verify the issuer's authority.
To connect to 10.65.127.9 insecurely, use `--no-check-certificate'.
So I get the certificate from the host:
openssl s_client -connect 10.65.127.9:443 <<<'' | openssl x509 -out /etc/pki/ca-trust/source/anchors/mycert.pem
And execute the following to process it:
update-ca-trust extract
This however results in the same issue.. If I run:
openssl s_client -connect 10.65.127.9:443 -showcerts -debug
I do get some errors and various messages:
depth=0 CN = us6877vnxe7827
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = us6877vnxe7827
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=us6877vnxe7827
i:/CN=us6877vnxe7827
Server certificate
subject=/CN=us6877vnxe7827
issuer=/CN=us6877vnxe7827
---
No client certificate CA names sent
---
Verify return code: 21 (unable to verify the first certificate)
Any ideas what I may be missing? If any further info helps, please let me know.
For wget you need to provide the certificate authority (CA) certificate(s) that signed the https server certificate. If you have those CA certificates - add them under --ca-certificate=file or --ca-directory=directory options
If you don't have them and you want to skip https server certificate verification (unsecure and can be dangerous) then use --no-check-certificate option.
I had the same problem with Jenkins trying to connect to our GitLab server.
The server does have a valid official certificate in our case, but Java didn't except it.
You are right about downloading the certificate.
However, the application you are mentioning is probably running inside a Java Virtual Machine (as a lot of applications are).
So from the point that you downloaded the certificate to a PEM file, you may have to add it to the VM's trusted certificates instead.
This article describes how to do that. Hope it helps.