To install Mongo DB I can see two versions of installer one with SSL & other as without SSL.
https://www.mongodb.com/download-center?jmp=nav#community
My question is if I download with SSL installer & do not configure SSL then doesn't it same as without SSL installer. What is the need of without SSL installer at first place? Is there anything specific feature which comes in Without SSL installer?
I use Monggo DB in my application but not sure which one I should recommend to my customers as I have mix set of customers who want with/without SSL.
Atul
The difference between the SSL-included version running without SSL enabled, and the SSL-excluded version, is that the version without SSL does not have the SSL libraries even present. If you are concerned about security flaws in OpenSSL, for example, then maybe you should use the version compiled without SSL.
Related
I'm using Axios to post to a remote API. Although it has worked great for several years, the requests have suddenly started throwing an error "certificate has expired' - despite the fact that the certificate has not expired. The API's domain has a working Let's Encrypt cert which isn't up for its next auto-renewal for another 2 months. In addition, if I run the exact same code on a different OS, it works (I'm on Linux; if I reboot the same dual-boot machine to Windows, the same node script successfully completes all of its Axios calls).
Why might Axios have suddenly started reporting an expired certificate, when the certificate is not expired?
(Note: I'm aware that I can force Axios not to check the cert at all, but that is not the desired solution - I'd like to understand why it's failing and rectify it).
The DST root formerly used and by default still bridged by LetsEncrypt just expired.
(note edits 10/05)
nodejs should successfully connect to a server using a LetsEncrypt cert with the 'compatibility' chain (i.e. still using the bridge to DST, even though it's expired, for old Android) IF
it has the ISRG root cert in its truststore aka root list. By default nodejs uses a compiled-in root list and v8.0.0 up contains the ISRG root. However application code like axios can replace or extend the compiled-in list, in which case it's the version/contents used by the application that matter.
AND nodejs uses OpenSSL 1.1.0 up (my previous belief that 1.1.1 was needed proved wrong on more thorough testing) OR the DST root is removed from the truststore (you can't remove it from the compiled-in list, but if you use a replacement list, you can omit/remove it from that).
On Linux, at least a Linux distro with a package manager, nodejs is probably built to use the system-supplied OpenSSL; check what the package manager shows for dependencies, or whether ldd $(which node) lists some version of libssl and libcrypto (noting that different systems/packagers sometimes use version numbers for these library files that are related to, but NOT the same as, the OpenSSL version they contain!).
On Windows, OpenSSL is usually not installed, and when it is, not necessarily in a fixed place, so nodejs is normally built to use its own (static-linked) OpenSSL. In this case the version of nodejs must be new enough, and I don't know what the mapping is, but it appears yours is sufficient.
Problem for me was I was using an old Node version by accident, switching to the latest released version fixed the issue.
I am using Red Hat 8 (rhel8), my home router is Asus AC5300 running OpenVPN server. But my rhel8 VPN in Network Manager can't not connect to my OpenVPN Server.
Here is the error message I got:
[root#my-machine ~]# journalctl -f
nm-openvpn[30404]: TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
[root#my-machine ~]# openvpn --version
OpenVPN 2.4.7 x86_64-redhat-linux-gnu
I've tried by adding tls-version-min 1.0 to my .ovpn file but still not working.
Note: In Linux Ubuntu it is working just fine, BUT not Red Hat 8
seems you have a problem with TLS ... take a look to this checks , maybe have to take a look SSL certificates:
Check for Certificate Name Mismatch
In this particular instance, the customer migrating to Kinsta had a certificate name mismatch which was throwing up the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error. As you can see from the SSL Labs test below, this is pretty quick and easy to diagnose. As SSL Labs states, a mismatch can be a number of things such as:
The site does not use SSL, but shares an IP address with some other site that does.
The site no longer exists, yet the domain still points to the old IP address, where some other site is now hosted.
The site uses a content delivery network (CDN) that doesn’t support SSL.
The domain name alias is for a website whose name is different, but the alias was not included in the certificate.
Certificate name mismatch
Another easy way to check the current domain name issue on the certificate is to open up Chrome DevTools on the site. Right-click anywhere on the website and click on “Inspect.” Then click on the security tab and click on “View certificate.” The issued domain will show in the certificate information. If this doesn’t match the current site you’re on, this is a problem.
Check issued domain on SSL certificate
Check issued domain on SSL certificate
Remember though, there are wildcard certificates and other variations, but for a typical site, it should match exactly. However, in our case, the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error actually prevented us from being able to check it in Chrome DevTools. That is where a tool like SSL Labs can come in handy.
Check for Old TLS version
Another possible reason is that the TLS version running on the web server is old. Ideally, it should be running at least TLS 1.2 (better yet, TLS 1.3). If you are a Kinsta customer you never have to worry about this as we always upgrade our servers to the latest and greatest supported versions. Kinsta supports TLS 1.3 on all of our servers and our Kinsta CDN. Cloudflare also enables TLS 1.3 by default.
(Suggested reading: if you’re using legacy TLS versions, you might want to fix ERR_SSL_OBSOLETE_VERSION Notifications in Chrome).
This is something the SSL Labs tool can also help with. Under configuration, it will show you the current version of TLS running on the server with that certificate. If it is old, reach out to your host and ask them to update their TLS version.
TLS 1.3 server support
TLS 1.3 server support
Check RC4 Cipher Suite
Another reason according to Google’s documentation for ERR_SSL_VERSION_OR_CIPHER_MISMATCH is that the RC4 cipher suite was removed in Chrome version 48. This is not very common, but it could happen in say larger enterprise deployments that require RC4. Why? Because everything usually takes longer to upgrade and update in bigger and more complex configurations.
Security researchers, Google, and Microsoft recommend that RC4 be disabled. So you should make sure the server configuration is enabled with a different cipher suite. You can view the current cipher suite in the SSL Labs tool (as seen below).
Cipher suite
Cipher suite
Try Clearing the SSL State On Your Computer
Another thing to try is clearing the SSL state in Chrome. Just like clearing your browser’s cache this can sometimes help if things get out of sync. To clear the SSL state in Chrome on Windows, follow these steps:
Click the Google Chrome – Settings icon (Settings) icon, and then click Settings.
Click Show advanced settings.
Under Network, click Change proxy settings. The Internet Properties dialog box appears.
Click the Content tab.
Click “Clear SSL state”, and then click OK.
Restart Chrome.
Clear SSL state in Chrome on Windows
Clear SSL state in Chrome on Windows
If you are on a Mac, see these instructions on how to delete an SSL certificate.
Use a New Operating System
Older operating systems fall out of date with newer technologies such as TLS 1.3 and the latest cipher suites as browsers stop supporting them. Specific components in the latest SSL certs will simply stop working. Google Chrome, in fact, pulled the plug on Windows XP back in 2015. We always recommend upgrading to newer operating systems if possible, such as Windows 10 or the latest version of Mac OS X.
Temporary Disable Antivirus
The last thing we recommend trying if you are still seeing the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error is to ensure you don’t have an antivirus program running. Or try temporarily disabling it. Some antivirus programs create a layer between your browser and the web with their own certificates. This can sometimes cause issues.
I have a p2site hosted on my server to provide Eclipse Update Site. The server is running an IIS 7.5
I have the same p2site content stored and provided both in my production environment and in my staging environment (two separate servers, with identical characteristics).
From a couple of days, if I connect with my staging environment p2site from an Eclipse Indigo instance, I'm required to enter credentials, which has never happened before.
Moreover, if I manually download the zip archive and install my plugin from this local archive, I'm asked the credentials too.
I can guess, but I'm not sure, that the problem can be related to the following: in the last days we have added HTTPS enablement for our web site, and installed our certificate in the root certificates of Windows Server 2008 R2.
Anyone knows why Eclipse (Indigo, haven't tested the other platforms yet) is behaving in this way?
And how can I prepare my local zip archive / p2site to overcome this issue?
Thank you very much
cghersi
Just for the sake of completeness, I found the solution on my own: the problem was that for some reasons (that I cannot still recognize...) there was a DENY rule in the .NetAuthorization section for the verbs OPTION,HEAD.
It seems that Eclipse send exactly these kind of requests when looking for p2site and so these requests were rejected and Eclipse was asking for credentials for these requests.
Hope is can be useful in the future for other people.
cghersi
I normally develop in ruby and serve my developement site with pow.cx.
For some client work I have to work with php and drupal. I had quite a bit of set up problems and incompatibilities between apache / php / Mamp and my pow server.
I've tried to set things up as mentioned there:
https://github.com/37signals/pow/wiki/Running-Pow-with-Apache
When I leave Mamp on port 888 everything is fine, but when i want to run mamp and pow on port 80 i start to have regular problems.
To try to fix the issue I have installed Apple Server app.
I now regret it.
If i turn websites on in the server app. Server takes over my pow url.
If i turn websites off, i can't access the pow url at all (says i have to turn websites on).
If i remove the Server app completely and restart, i can access Pow again, but Mamp refuse to start apache, saying that it can't resolve the domain name set up by the Server App.
So Is there a way to remove and clean the Server app setup completely?
I'm not sure what the cleanest way to remove the Apple Server app. But at least I manage to get Mamp work again.
I had ot add an alias in my /etc/hosts files with the current name of my local machine
127.0.0.1 my-lovely-mac
and now Mamp Apache is all happy again
I am currently attempting use Adobe RDS built into Coldfusion Builder to connect to our servers RDS setup, no matter how I set it up to match Dreamweaver CS4 RDS it fails.
Everything through Dreamweaver RDS works fine, but I would rather use cf builder, any ideas or links?
Is the HTTP connection over SSL/HTTPS?
If so it's possible that the SSL certificate you are using to connect isn't recognized by the JVM as a trusted ssl cert. In which case you would have to add your cert manually to the java keystore.
Beta 2 of CFBuilder was released to the Labs on Monday - maybe give that a try and see if it solves the problem?