I wanted to write out this question here for anyone looking to resolve issues related to SSL certificate. I know that there are a lot of solutions out there (setting any form of sslVerify = false IS NOT the solution people!) for both Windows and Linux-based machines, but none of them works out for me at my company. This has been an on and off issue for the past year, so I'm hoping this might help out someone else.
If you've seen anything similar to the following errors, this might be a good stepping point to a solution:
curl (60) SSL certificate problem: unable to get local issuer certificate
PHP Warning: no valid certs found cafile stream
Composer: The [repo] file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Then check out Matt Ferderer's post (https://mattferderer.com/fix-git-self-signed-certificate-in-certificate-chain-on-windows) and pay specific attention to the certificate path (image).
For me, there were a good number of posts about how a company's firewall might cause an issue. But the idea that a company's IT department may have other applications that intercept the request you're sending out is something to consider. It was Matt's specific post that was the turning point in my hunt for a solution. I hope it might help you out.
Specifically for me, after viewing the certificate path (described in Matt's post), I noticed that my company's cloud security application was, for some reason, altering the certificates, causing the SSL verification error. The IT department was able to update the settings of the application, and then immediately all of the errors stopped.
Related
I've tried applying some of the following SO answers to an ES server:
Link 1
Link 2
However, I always get a SSL certificate authentication error.
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
More details here: https://curl.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.
Is there a workaround for this?
If you are using ElasticSearch for local purpose and do not worry about security issues, you could disable security settings as it described here.
For example, for Linux you could change every configuration with "security" word from true to false in the elasticsearch configuration file: elasticsearch-8.2.0/config/elasticsearch.yml
Hope this helps!
I have an application that receives items from a high-speed scanner device. As the items are received, they are written to disk using SQL Compact. The following digitally signed Microsoft DLLs are used:
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
I recieved a performance complain from a customer, and traced the issue using Microsoft Procmon to a TCP Reconnect failure when attempting to contact the site for certificate validation when we make calls to methods in these dlls. At first, I could not recreate the issue locally. After talking to their infrastructure people and developers, I learned that they must use a proxy for internet connectivity. Some of the customer's users (in the test environment) had valid proxy settings, and they got good performance from our application. Naturally when they turned their proxy settings off, the validation could not be done and the performance issue arose.
I attempted to recreate the issue by setting our machine up with false proxy settings to a non-existent machine. On my initial attempt, I still got good performacne from our application, and no attempt was made to contact the internet for cert validation. After looking at the cert's validation chain, I noticed that it derived from the certificate "Microsoft Root Certificate Authority". I then exported and deleted that Cert, and was able to reproduce the issue as determined by a comparison of logs.
I did the following tests:
Test 1:
1. Opened the proxy settings, and enabled them pointing to a non-existent address.
2. Ran a test.
Results: No performance issue.
Test 2:
1. Exported the “Microsoft Root Certificate Authority” cert and moved it to the untrusted folder.
2. Ran a test.
Results: The performance issue occurred.
Test 3:
1. Deleted the “Microsoft Root Certificate Authority” cert.
2. Started a test.
Results: The performance issue began occuring.
3. While the test was in progress and device was hesitating I removed the false proxy settings.
Results: The performance issue disappeared and the application recovered.
Tentative Conclusions:
1. That I can simulate the no internet access condition by providing false proxy settings.
2. If the “Microsoft Root Certificate Authority” cert is installed properly, the .Net infrastructure does not need to access the network to verify the necessary cert.
3. If not, it will attempt to validate via the internet connection.
Nevertheless, when the customer checked the certificates in the "Trusted Roots Certificates" folder of mmc->certificates-local computer. The "Microsoft Root Certificate Authority" certificate does appear there, and it seems to be identical to mine. Yet for some reason the use of the dll's causes certificate validation to attempt to access the internet resulting in a performance issue.
In the customer's situation, eventually devices will be used in production with no internet access.
My question is, is there a setting (registry, or GPO) that might cause certificate validation to always attempt to use the internet, regardless of whether the root certificate of the validation chain is installed in the local computer?
Can a setting be enabled that causes a certificate validation to access the internet to check to see if the root certificate has been revoked, for example?
Please feel free to ask questions if you need more information.
This appears to occur for SQL Server Compact 4.0 on any system with an invalid proxy configuration, as a Certificate Revocation List check is run each time the engine is loaded (which happens on the first call to .Open()).
Solution: To avoid this delay, which probably affects any signed app on the system in question, you must fix the configuration or disable the check. The check can be disabled via UI or via registry settings, as described here: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282
For additionla issues see my blog post here: http://erikej.blogspot.com/2013/08/faq-why-is-opening-my-sql-server.html
I've been using Bitbucket for 2 years on my Macbook. Today I went to view one of my depots but I am getting the error message, Your connection is not secure. All other sites works, it's only Bitbucket.org that is giving me this error. I've tried using Safari and Firefox, neither work. I also can not connect using SourceTree. I am able to connect on my Windows computer so that rules out my router. I've deleted all expired certificates in Keychain and deleted cookies and cache. Does anyone know what the issue might be?
The Macbook's clock is set automatically and is displaying the correct time. In Firefox, when the website fails to load, I can see these 3 messages by clicking the Advance button,
bitbucket.org uses an invalid security certificate.
The certificate is only valid for search.dnsadvantage.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN.
If I click on the last error, it opens another page which displays, https://bitbucket.org/ Unable to communicate securely with peer: requested domain name does not match the server's certificate. HTTP Strict Transport Security: true HTTP Public Key Pinning: false.
Is there somewhere else I need to go to locate more information about the error?
Looks like you've picked up a virus and/or malware:
http://www.fixingvirus.com/always-redirected-to-search-dnsadvantage-com-how-to-stop-it/
That link is for Windows machines so maybe check this for Macbook?:
https://www.fixyourbrowser.com/how-to/remove-adware-mac-osx-safari-chrome-firefox/
Note I don't vouch for above links but first ones that came up when I Googled for "search.dnsadvantage.com". Seems a common problem.
after recent windows updates (Windows 7) - I'm getting error when verifying digital signature on some files.
The verification fails for Countersignature certificate:
Anyone has the same issue? Or maybe found a resolution?
Thanks,
Zahar
Looks like a connectivity issue - the CRL for some certificate can not be downloaded by he client. You need to inspect the certificates on the screenshot, check their properties and find CRL Distribution Point extension there. It's likely that you will find http://crl.verisign.com/tss-ca.crl there. Then you need to check if you can connect to this URL from the browser. If you can't, then the problem is either in the firewall or in some other network component.
We had an issue with our automated build machine yesterday. We are using a TFS Build server, and when it tried to automatically download NuGet packages, we got the infamous "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error.
There are a lot of threads around the 'net regarding why this happens. That isn't my question. It can be fixed easily enough by changing your NuGet repository from
https://nuget.org/api/v2/
to
http://nuget.org/api/v2/
or
http://packages.nuget.org/v1/FeedService.svc/
What I'd like to know is why the repository is using SSL in the first place? I assume it is there for a reason, but I can't figure out what. There is no login that would require security. I can't think of any information being sent that would need to be secure. I just want to make sure that by using an unsecured connection (which works just fine) we aren't somehow compromising our build machine.
Can anyone explain what is gained from connecting to NuGet using a secured connection?
I can't think of any information being sent that would need to be
secure.
It is not necessarily because the information you exchange with nuget.org contains anything secret and thus needs to be secure. By using using SSL you will be certain that it actually is nuget.org you're talking with. Without SSL, somebody might in theory be feeding you bogus packages, and that might be a security problem.
As for the issue you're experiencing with "Could not establish trust relationship for the SSL/TLS secure channel", we've had a similar problem when we started using a new build server:
If you look at the SSL certificate presented by https://nuget.org/, the certification path is: GeoTrust Global CA > RapidSSL CA > *.nuget.org
GeoTrust Global CA was missing as a trusted CA on our new build server, so the problem was easily solved by adding them to the build servers list of trusted root CAs (using the MMC console with the Certificates snap-in).
Update:
On a later service, I've experienced the same SSL issue, and adding GeoTrust as a trusted CA alone didn't solve the problem. In addition, the server was also missing to root CA for https://go.microsoft.com/, which is Baltimore CyberTrust Root (go to https://microsoft.com, and you'll be able to view and download the certificate). Adding this to the servers list of trusted root CAs solved the issue.