I have a raspberry pi setup using Raspbian Buster and created an OpenSSL Certificate Authority I intend to use with a mobile app. The root CA signs an intermediate CA that signs the server certificate for a MariaDB MySql server and using a self-made WebAPI, it can sign certificate signing requests for clients to access the DB (clients and the server must both be authenticated).
I can connect to the database over the MariaDB client, using SSL and requiring the client to authenticate its certificate, however if I revoke the client certificate it still allows access. It appears that on the Raspberry Pi, MariaDB runs 10.3 and uses the yaSSL library instead of OpenSSL, even though the OpenSSL library is on the Pi.
Is there a way I can make MariaDB use OpenSSL rather than yaSSL as openSSL supports crl_path, which is required for mariadb to check the revocation list and deny access to revoked certificates as explained here. Another option would be to use MariaDB 10.4 however I believe it must be compiled from source which i tried to no avail, or use another OS which I would not like to do.
I'm attempting to do the same but using 10.5 stable released source. It's currently compiling ...
There is a build configuration switch that cmake needs to make it compile with openssl: cmake -DWITH_SSL=SYSTEM
That will make the make use the OS provided SSL library which in my case on Raspberry Pi4 Raspbian Buster 64 bit is openssl.
After you run cmake you can double check by running cmake -LH which should show openssl in the list.
(Yeah, I've no idea who made the bright decision to disable SSL on mariadb for raspbian buster !)
Related
After installing mongodb on CentOS 7 I ran into an issue with openssl versions. Version installed on the system is 1.0.2k-fips whereas during mongod startup 1.0.1e-fips is printed. How exactly is this possible and is there any way to tell mongo server to use 1.0.2 version ?
https://i.stack.imgur.com/KMbwt.png
This seems to be a RHEL peculiarity.
MongoDB is linked dynamically against OpenSSL, and should use the system OpenSSL library. You can verify this by running
ldd `which openssl`
ldd `which mongod`
The two commands should show references to the system-wide libssl and libcrypto.
What I think happened is RedHat updated OpenSSL from 1.0.1e to 1.0.2k, but retained the "1.0.1e" label for compatibility purposes in parts of the code.
So indeed, MongoDB is using system OpenSSL library, which can be verified with ldd.
The issue with version misinformation is because since a while ago (RHEL 6.x releases), RedHat changed SSLeay() function to report build time version as opposed to the run-time:
Because certain applications perform incorrect version check of the OpenSSL version, the actual runtime version of OpenSSL is masked and the build-time version is reported instead. Consequently, it is impossible to detect the currently running OpenSSL version using the SSLeay() function.
MongoDB uses this exact function to report OpenSSL version, here.
So when you use MongoDB packages and see 1.0.1e-fips while the system OpenSSL version is 1.0.2k-fips, this only means that the system where the package was built on had the older OpenSSL version, but the actual runtime version is your system one, 1.0.2k-fips.
I want to run Visual Studio Code Remote Development using SSH to my Raspberry Pi 3 Model B+ running Raspbian GNU/Linux 9 (stretch).
I have tried to follow the "Getting started" instructions. I run the command Remote-SSH: Connect to Host..., but I get the message Can't connect to admin#pihole.local: unreachable or not Linux x86_64 (Linux armv7l )
As far as I know, Raspbian is 32 bit. So, does this mean that what I want to achieve is impossible?
I can connect to the Raspberry Pi using ssh on the command line without problems (not password based).
I'm running VS Code insiders on macOS Mojave 10.14.4.
Update 2: As of the 10th of February, x86_64, ARMv7l (AArch32) and ARMv8l (AArch64) are the supported Linux architectures for Remote SSH. It it appears that a glibc based Linux distribution is needed to meet certain prerequisites/dependencies. There is also experimental support for Windows 10/Windows Server 2016/2019 in the Insiders builds. More information can be found on the prerequisites information page.
Update: As of the 12th of June, approximately one month after my answer to this, support was added for the Raspberry Pi 3. There is no support for other ARM architectures yet, and this does not work with the Raspberry Pi Zero W yet, but I'm not sure about the Raspberry Pi 1 or 2. One point to note at present is that you need to setup public key authentication so you have passwordless login, otherwise you'll need to enter your Raspberry Pi's password multiple times, and it will ultimately fail. Also, as mentioned in a comment, if you've tried the 'stable' Remote Development extensions and found out they didn't work... you need to make sure you remove them from both VSCode AND your Raspberry Pi... else it really won't work. This is also mentioned in the Github issue.
Because of how the Remote SSH function actually work, when you connect to your SSH host, the Remote SSH extension provisions the so-called VS Code Server to that host, so the VS Code Server has to be able to run in your remote environment. Consequently, at present, each architecture may need different implementations or tweaks, before it will be considered 'supported'. At the time of writing, there are no armv7l builds, but this recently changed. We're still early days for this useful looking functionality... but things are changing quickly... There is no Windows or MacOS SSH host support at present... but this may not be the case in another months time.
There is an issue open on GitHub on this topic, so it may be worth keeping an eye on it or subscribing to it to see if/when support is added.
I have installed Citadel mail server on my Raspberry Pi 3 running raspbian with apache2 because I am already running a nextcloud server on it.
The installation process completes without any errors.
I am able to get on the citadel's login screen with my browser on port 8080 and I can't seem to get passed the login screen.
Login and password is correct. I know that because I don't get any errors like wrong password or user does not exist, after clicking login I get nothing. Login page just refreshes.
I tried those commands
sudo mkdir /etc/citadel/netconfigs
sudo chown citadel:citadel /etc/citadel/netconfigs
and
sudo service citadel restart
sudo /usr/lib/citadel-server/setup
Didn't change anything.
Tried purging and reinstalling the suite, reconfiguring everything and I get to the same point.
I made sure to delete any remaing files or configs before reinstalling so I am out of ideas.
If you need any more information or have me to check error logs, just make sure you tell me how :) I'm definitely not an expert.
Thanks in advance!
I had this on a Pi. Try using Easy Install. My comments in []
Easy Install requires a working build environment. This is installed by default on many Linux distributions. [But not Pi] Otherwise, to install a build environment use the following commands (as root):
apt-get update
apt-get install build-essential curl g++ gettext shared-mime-info libssl-dev zlib1g-dev
Then run Easy Install the normal way:
curl http://easyinstall.citadel.org/install | bash
[from http://www.citadel.org/doku.php?id=installation:easyinstall:easyinstall]
This compiles Citadel so will take some time. If this seems not to work just run again. this time is very fast, and will let you do the setup.
As a small update to this issue, you may find installing Ubuntu Server 18.04 on your Pi 2/3 a lot smoother. Ubuntu now offers their own proper server images for RPi.
As of 18.04 the Pi wireless drivers are included, and Citadel installed effortlessly and fully (inc. login) functional.
I have 18.04/Citadel running with 140Mb/RAM and about 2% CPU whilst idle using the Pi 3B+.
UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.
I am using the SOAP::Lite module
SOAP::Lite is based on LWP. The https support in LWP is ultimately done by using the OpenSSL library. My guess is that you are using a very old OpenSSL library with no support for TLS 1.1 and TLS 1.2, typically either OpenSSL 0.9.8 or OpenSSL 1.0.0 since support for TLS 1.1 and TLS 1.2 was only added in OpenSSL 1.0.1. Such old OpenSSL libraries are typically installed on older systems but also on newer MacOS systems.
To fix the problem you need to upgrade both OpenSSL and the Perl-bindings for it (Net::SSLeay on newer systems or Crypt::SSLeay on older, depending on your version of LWP).
I'm using Eclipse (Indigo) with subclipse 3.6 in Ubuntu 11.10.
I've connected to the svn with subclipse on other machines before no problem, but with my recently upgraded ubuntu machine (went from 11.04 to 11.10) it won't work.
when I try to connect to my private svn server (VisualSVN Server in Windows), I get the following error:
RA layer request failed
svn: OPTIONS of 'https://76.27.122.123/svn/brock':
SSL handshake failed: SSL error: Key usage violation in certificate has been detected. (https://76.27.122.123)
Key usage violation in certificate
So, googled it, and found this solution: http://andrewbrobinson.com/2011/11/01/fixing-ssl-handshake-failed-ssl-error-key-usage-violation-in-certificate-has-been-detected-error-on-svn-checkout/
Which basically says that because neon is now using GnuTls, and it is being strict and rejecting my invalid certificate (like I said it's a private svn so it is untrusted).
But when I do the mv and symbolic link commands, it then messes up my JavaHL setup, and gives me this error:
Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path ...
I undid the mv command and now the JavaHL is working after following instructions I found here http://subclipse.tigris.org/wiki/JavaHL#head-5ccce53a67ca6c3965de863ae91e2642eab537de but still can't get past the key usage certificate error. Any ideas??
During the initial setup VisualSVN Server 2.5 generates a self-signed certificate and adds it to the Trusted Root Certification Authorities store on the local machine. To avoid possible security issues, VisualSVN Server makes this self-signed certificate to be valid for server authentication only (by specifying the 'Key Usage' extension).
Subversion clients built against GnuTLS don't recognize such certificate and the error occurs.
Possible workarounds:
Sign certificate using trusted certification authority (recommended)
Use VisualSVN Server workaround to generate a cerificate without specifying 'Key Usage' extension. See KB56 for detailed instructions.
Configure eclipse to use Neon with OpenSSL instead of GnuTLS
Alternatively you might add
alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'
to your .bashrc, so only the svn command would be affected by the libneon change, and not the other packages. Also be careful that the solution mentioned in your link will break under Ubuntu 12.04 LTS. For that you have to use these steps:
Uninstall the current libneon package:
sudo apt-get remove libneon27
Download the latest libneon package from http://packages.debian.org/squeeze/libneon27 (at the bottom you can choose the right version for your architecture).
Install the required libssl dependency:
sudo apt-get install libssl0.9.8
Install the downloaded libneon package. E.g. for the 64Bit architecture:
dpkg -i libneon27_0.29.3-3_amd64.deb
Add
alias svn='LD_PRELOAD=/usr/lib/libneon.so.27 svn'
to your .bashrc, and relogin.
Source: http://www.yeap.de/blog2.0/archives/260-Subversion-Certificate-Problems-with-Ubuntu-Precise-Pangolin.html