I'm using Netbeans with automatic upload to server each time I save a file locally. I suddenly started running into this error:
Cannot connect to server xxx.xxx.xxx
(Cause: java.security.cert.CertificateExpiredException: NotAfter: Sat May 30 12:34:56 CEST 2020)
I've checked my server (running Apache with cPanel/WHM on AWS EC2), and all SSL certificates seem to be updated and valid. I can connect to the same server using FileZilla. I'm using FTP with explicit TLS in both FileZilla and NetBeans.
I first got this error on my legacy Netbeans 8.2 installation, so I tried updating to 11.2, but I get the same error. Possibly because it duplicated my settings from 8.2?
(If I connect without encryption, it works.)
Hopefully my own experience with that issue helps you along, though I have not fixed it for myself, yet.
It seems, that not the server's certificate is invalid, but the root-certificate against which it is checked by the java-JRE has expired. see https://www.ssl.com/blogs/addtrust-external-ca-root-expired-may-30-2020/ - These root-certificates are normally stored locally with the OS. But some applications come with their own keystore.
And since JRE apparently does not use the OS's certificate store, this might explain FileZilla behaving differently.
I tried updating my local Java-installation to no avail. I also tried to find the out-of-date root-certificate in the Java-config. And indeed, it is listed with the "appropriate" valid-until date. But temporarily removing it, did not help. No luck there, either.
Related
I have been going around and around with this issue. I can create a dev-cert using dotnet dev-certs https --trust but the certificate only appears in the Personal certificates folder. If I try copying it to the Trusted folder it disappears on refresh. I have watched videos of people doing this on YouTube and it works so I'm not sure what is wrong with my PC/install.
Running my code and hitting the route in Postman returns a 500 error and UntrustedRoot.
I have tried this using a local user account and my admin account. I have also tried creating a certificate and importing it using OpenSSL following guides I have found, but still no luck.
I am running Windows 10 Pro on a new build PC. Windows was a clean install with a new licence.
I really don't want to have to purchase a signed certificate just to do development on localhost as that seems a bit overkill.
Any suggestions?
tl;dr try disabling your anti-virus before creating certificate!
I finally stumbled upon the answer; my anti-virus, WebRoot. I was following a YouTube tutorial on how to add a custom certificate to Kestrel and in doing so I discovered that WebRoot was blocking access to the hosts file. Disabling the av allowed me to update that file but also, it then allowed trusting of the dev-cert generated by dotnet dev-certs https --trust.
Not sure how I can prevent this in future other than temporarily disable the av before creating a certificate. Frustrating that the av doesn't warn me and there doesn't appear to be an obvious setting to allow this to happen.
So with the help of Graham I realize I need to rebuild the mod_ssl.so to point to the new OpenSSL version.
I found the following post with similar problem but not much suggested: https://stackoverflow.com/questions/36756641/rebuild-mod-ssl-so-on-apache2-on-macosx
Is it possible to only rebuild the mod_ssl.so only or do I need to rebuild Apache?
Any specific flags to use?
Is homebrew the way o go and how do I avoid having two installations of Apache?
I am on 10.11.6 and using MacOS Server 5.2 (If that has an impact)
I have integrated the following framework under a flask app and made it work. https://github.com/playingmedia/swish-python
So basically it makes a Request with pyopenssl with included certificates.
This is working fine in my flask app, but when I move it to my Apache Server (configured to be accessed through TLS - not sure if that is relevant) it gives me the following error: SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)
I am wondering if there is mod_wsgi setting I need to manipulate of there could be any permission issues...
I included another framework using Suds with TLS without on the Apache server any problem so wondering if there is any known issues with Request library and pyopenssl under mod_wsgi?
Have tried to google quite a lot but perhaps I am not typing in the right key words
Thx
Recently I have been plagued by an error on committing to a single SVN repo using TortoiseSVN (1.8.7.25475) or AnkhSVN (2.5.12471.17):
Error running context: The server sent an improper HTTP response
Here is a screenshot of the error in TortoiseSVN:
The pixels differ of course, but the error is the same in AnkhSVN.
This only seems to affect attempts to commit modifications, not additions or deletions; and I can commit mods to several other SVN repos on the same server just fine.
Since my teammates continue to commit mods to the repo in question and the issue has only struck my commits to that repo, I tried committing simple mods after a fresh checkout of the repo: a few one-mod-at-a-time commits worked, but then...same error.
I also searched for, reviewed, and tried some possible solutions (e.g. in a thread on the TortoiseSVN forums to which Stefan Küng replied) - a registry tweak (deleting HKEY_CURRENT_USER\Software\Tigris.org - after exporting it for backup of course), checking my global properties, and ensuring that I am not using a proxy. Same error.
Finally, I tried both repairing and downgrading TortoiseSVN. Same error.
Has anyone else encountered this error under similar circumstances and found a solution to it?
Note that some related search results mention tweaking httpd.conf or other aspects of the SVN server, but server tweaks seem inappropriate to me. Again, my teammates continue to commit mods to the same repo using the same version of TortoiseSVN, the same OS (Win 7 Pro 64-bit) etcetera. Maybe I have missed something on the server that could just happen to affect me, though.
Upgrade your Subversion client to the latest version.
Outdated answer:
ON THE CLIENT MACHINE! Open %APPDATA%\Subversion\servers in a text editor and add the line http-bulk-updates = yes, save the file and see if it helps.
If it helps, you'd better configure Apache HTTP Server's httpd.conf with SVNAllowBulkUpdates prefer directive so that all Subversion 1.8 clients could connect without any errors.
If there are more than just you who get this error in your organization and adjusting server's configuration is still unacceptable, you can change the setting http-bulk-updates = yes via Windows Registry so adjusting this on all affected machines can be done via AD Group Policy.
Read more info in Apache Subversion 1.8 Release Notes.
P.S.: faulty network hardware / firewall / antivirus is still the root cause here. The above is just a workaround to revert to the behavior of Subversion 1.7 and older client with neon network library. BTW, I guess that the installed antivirus is NOD32 or BitDefender.
In my case it was problem with nginx's gzip (I run SVNEdge SVN server behind Nginx).
I disabled gzip and everything started working.
I have:
Installed XCart (Gold Plus 4.6.0 - Trial with Lexity Live) on Netfirms
Purchased (and successfully installed) a RapidSSL Premium Certificate from GeoTrust through Netfirms
Enabled SSL in XCart and updated config file appropriately.
When I run Settings::Security Settings I receive error under HTTPS Options, "Warning! HTTPS/SSL check failed. Please make sure that HTTPS is configured properly."
Question: If the certificate is installed and the software knows to go to the secure server address what could be the problem?
I realize more background info is necessary. Please help. I know nothing of ssl. I read somewhere quickly in the past year or so something about symlink-ing, etc. I don't believe this to be of use here. Perhaps I am incorrect.
All my love,
Once you have SSL configured in your browser, it should just work. Make sure your cert is actually installed correctly.
You can test it with the SSL Installation Diagnostics Tool.
If that actually comes back ok for your site, then your best bet will be to check the syslog, perhaps something is not configured properly in your webserver config?
Sometimes this appears, sometime not. Its since two days in former good running apps.
CurlException: 60: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed thrown in
With a former Version of the php SDK, I disabled CURLOPT_SSL_VERIFYPEER generally besause that never works. But the last two versions, now its the newest, worked until yesterday.Shout I disable something again? Is it the same method in the actual SDK? Writing from home, can't look inside.
Is it a message from the cert coming with the sdk or are that problems with the cert of https on my server?
You shouldn't disable CURLOPT_SSL_VERIFYPEER because of the security implications. The PHP SDK usually contains the needed certificate, but in your case it seems to have problems.
The best way to solve it is:
Download the Facebook SSL certificate here
Put it somewhere accessible by PHP
Tell the Facebook PHP SDK to use it:
Facebook::$CURL_OPTS[CURLOPT_CAINFO] = '/path/to/fb_ca_chain_bundle.crt';
I just ran into this same error (coworkers didn't have it) and the solution was to download a new copy of the Facebook API SDK from https://github.com/facebook/facebook-php-sdk. Apparently my version (and the certificate) was outdated.