The server I am trying to establish a connection to is using TLS1.2 with a self signed certificate. Since browsers like chrome don't accept them anymore, I deployed websockify with a verifiable certificate and that works fine. The part where is failing is the TLS connection between websockify and the server. If I set that connection with a server that is not encrypted everything works as it should.
the server gives me a cafile and a subject string and a ssl_cyphers. How can I use them to configure websockify proxy to make that second part of the connection encrypted.
This is what I tried. Only thing missing is the host-subject which I am not sure how to set. My understanding is the first part of the command correspond to the left side of the proxy connection and the 2nd part (separated by empty line) the target socket connection. Let me know if I misunderstood this part as well.
/var/www/websockify/run 5959 \
--verbose \
--ssl-only
--record /tmp/websockify.log \
--cert=/etc/letsencrypt/live/ws1.xxxx.net/cert.pem \
--key=/etc/letsencrypt/live/ws1.xxx.net/privkey.pem \
--ssl-target \
--cafile=${CAFILE} \
--ssl-ciphers='HIGH:!aNULL'
${host}:${tls_port}
Got it working. needed to force the ssl-version to what I needed in this case tlsv1_2
Related
Migrating from one service to IBM Cloud for Redis.
I cannot find the correct configuration to connect using TLS. Everything I find on this is related to Heroku. and it ignores verifying the TLS/SSL connection.
I cannot find how to configure our Sidekiq/Redis to connect.
I do have a certificate from the IBM Cloud dashboard and I suspect I have to pass that along somehow.
Configure the Sidekiq.yml like this
:redis:
:url: "rediss://:< PWD >#< DB Name >:< PORT >/0"
:namespace: "app"
:ssl_params:
ca_file: 'path/to/cert'
I keep getting back the error Redis::CommandError - WRONGPASS invalid username-password pair or user is disabled.: however using these same credentials in the migration script I am able to connect to the DB, so the credentials are ok, I think it is not including the certificate correctly and I cannot find the correct way to do this
The sidekiq.yml configuration looks good to me, just make sure this has correct complete path
ca_file: 'path/to/cert'
and change the redis url to
:url: "rediss://< PWD >#< DB Name >:< PORT >/0"
further info you can read from here for TLS secured connection.
I'm not familiar with sidekiq.yml. But I've configured redlin with redis using a python script you can find here: https://github.com/IBM-Cloud/vpc-transit/blob/master/py/test_transit.py. Maybe the configuration is similar.
The relevant code is:
def vpe_redis_test(fip, resource):
"""execute a command in fip to verify postgresql is accessible"""
redis = resource["key"]
credentials = redis["credentials"]
cert_data = credentials["connection.rediss.certificate.certificate_base64"]
cli_arguments = credentials["connection.cli.arguments.0.1"]
command = f"""
#!/bin/bash
set -ex
if [ -x ./redli ]; then
echo redli already installed
else
curl -LO https://github.com/IBM-Cloud/redli/releases/download/v0.5.2/redli_0.5.2_linux_amd64.tar.gz
tar zxvf redli_*_linux_amd64.tar.gz
fi
./redli \
--long \
-u {cli_arguments} \
--certb64={cert_data} << TEST > redis.out
set foo working
I am facing an issue that I want to ask here.
I have a container that must reach an URL. But, because of root certificate problem, I cannot reach that URL.
When I am trying to curl from inside of container, I am getting below error.
***curl: (60) SSL certificate problem: certificate has expired
More details here .
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.***
I am trying to add this certificate and update them in Dockerfile with lines below.
ADD your_ca_root.crt /usr/local/share/ca-certificates/foo.crt
RUN chmod 644 /usr/local/share/ca-certificates/foo.crt && update-ca-certificates
but, getting this error.
What I have tried;
tried to delete entire certificates and install new ones.
tried to use "update ca-certificates -f"
But did not work.
So, any suggestions?
I am trying to write .netCore 3.1 API in an Ubuntu Linux container that runs the equivalent of this Curl command.
WORKING LINUX CONTAINER CURL COMMAND:
curl --cacert /etc/root/trustedroot.crt --cert /etc/mutualauth/tls.crt --key /etc/mutualauth/tls.key
--header "SOAPAction:actionName" --data #test.xml https://this.is.the/instance --verbose
Enter PEM pass phrase: *****
<Success...>
We use Windows development laptops so everything starts with Windows.
So far, I have the following HttpClientHandler that my HttpClient is using on a Windows development machine. This code works on Windows with the cert in my local machine and current user personal stores and does not work in Linux:
WORKING WINDOWS HTTPCLIENTHANDLER CODE:
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
try
{
var cert = store.Certificates.Find(X509FindType.FindByThumbprint, "<<cert thumbprint here>>", true);
var handler = new HttpClientHandler
{
ClientCertificateOptions = ClientCertificateOption.Manual,
SslProtocols = SslProtocols.Tls12,
AllowAutoRedirect = false,
AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip
};
handler.ClientCertificates.Add(cert[0]);
}
catch (Exception e)
{
//Handle errors
}
finally
{
store.Close();
}
The cert I imported was .PFX format so as I understand it, the password went in at the time of import and the code for Windows doesn't need to be concerned with it.
The Curl command mentioned above works from the container. So by that logic, if coded or configured properly, the code should be able to do the same thing. As I see it, the Curl command shown above contains four elements that I need to account for in my HttpClientHandler somehow:
The Trusted Root(CA) Certificate: /etc/root/trustedroot.crt
The TLS Certificate: /etc/mutualauth/tls.crt
The Private Key - /etc/mutualauth/tls.key
The PEM Passphrase
I have been reading into this for a couple of months now and have seen various articles and stack overflow posts but there is a staggering amount of variables and details involved with SSL and I cant find anything that directly addresses this in a way that makes sense to me with my limited understanding.
I also have the option of running a Linux script at the time of deployment to add different/other formats of certs/keys to the stores/filesystem in the container. This is how I get the certs and keys into the container in the first place, so I have some control over what I can make happen here as well:
LINUX CONFIG SCRIPT:
cp /etc/root/trustedroot.crt /usr/share/ca-certificates
cp /etc/mutualauth/tls.crt /usr/share/ca-certificates
cp /etc/mutualauth/tls.key /etc/ssl/private
echo "trustedroot.crt" >> /etc/ca-certificates.conf
echo "tls.crt" >> /etc/ca-certificates.conf
update-ca-certificates
dotnet wsdltest.dll --environment=Production --server.urls http://*:80
I do not believe I can get the binary .PFX file into the container due to security policies and limitations, but I definitely can get its string encoded cert and key formats into the container.
...so if there is a way of using different styles of certs that I can extract from the .PFX or specifying password and cert when the server 'spins up' to make my code not require a password, that would work too - I might just be missing something basic in the Linux config.
Would anyone be so kind as to point me in the proper direction to find out how I can uplift my HttpClientHandler code OR Linux config to be able to make this API call? Any ideas are welcome at this point, this has been a thorn in my side for a long time now... Thank you so much!
This was not the right approach.
The correct approach was an NGINX reverse proxy terminating mutual auth TLS so that Dotnetcore doesn't have to.
Save yourself some time and go NGINX!. :D
I am in process of creating an app using the following stack:
Python 3.6 + Flask
uwsgi
Nginx
executing inside a Docker Container.
This app in turn calls Jira API to gather and manipulate data. Most of the inbound to app are working fine. But, when the app tries to call Jira API, it is throwing the following error:
[SSL: CERTIFICATE_VERIFY_FAILED]
I believe, this issue is occurring due to a presence of a self-signed certificate in the chain (which is not avoidable).
I did import the certs into docker image and curl command worked fine (initially curl was also throwing the insecure warning).
Also, in order to isolate the issue, I switched off nginx and launched the app directly using uwsgi (uwsgi --socket 0.0.0.0:8080 --protocol=http -w [module]:[app]) and see the same error in uwsgi console.
Does this mean that I need to import the SSL certificate into uwsgi ?
If so, how exactly to do that. I don't intend to make my app secure using own certificate or keys.
This program works, if I purely run the flask app without any uwsgi, nginx and docker.
[edit] Adding Nginx config
server {
listen 8080;
location / {
try_files $uri #app;
}
location #app {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}
location /static {
alias /app/static;
}
location = / {
index /static/index.html;
}
}
uwsgi-directly invoking it using CLI for debugging
[Edit2]
So I did some more troubleshooting:
Created one simple script which is just calling the Jira url
Ran the script in my local (mac os) using python3 [scriptname]. This worked fine and printed a 200 OK
Copied the same file into my container and ran the same code.
Got the same issue.
Used the same URL with CURL and it got the response.
It seems that even though curl works fine, python itself is throwing the SSL error.
So NOW the question may be, how to handle SSL error with python !?
I was finally able to resolve the issue. The issue was related to request call being made by the code.
By default, the request calls have verify set to true. Also, request uses in-built certs for verification.
In my case, since I was using custom certs, request was failing to validate the Jira site.
In order to solve the issue, I created an ENV variable in docker file and pointed request to refer to my image's certs directory.
Exact line
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/
Do note, the custom certs should still need to be imported into docker image during build.
This error also happens when crt or pem file is not a bundle certificate file.
To make a bundle, issue this command:
openssl pkcs12 -in my_certificate.pfx -nodes -nokeys -out server-bundle.pem
if you need your server key also, then issue:
openssl pkcs12 -in my_certificate.pfx -nocerts -nodes -out server.key
And update SSL certificate entries on apache or nginx config file and restart and then verify with:
http https://yourdomain.com
or
http --debug -j --verify server-bundle.pem https://yourdomain.com
I want to configure freeRADIUS server as a authentication server for enterprise WLAN testing. I'm new to freeRADIUS server configuration. please give me the step by step or any link for installation and configuration
Thanks,
Devaa
First we’ll need a place to work, so I created a directory:
mkdir /usr/src/freeradius && cd /usr/src/freeradius
Next we need to fetch our source and get any dependencies, so update your sources and enter the following commands:
apt-get update
apt-get build-dep freeradius
apt-get install libssl-dev fakeroot
apt-get source freeradius
This should have downloaded the FreeRADIUS source code for us, so now we’ll have to make a few changes to tell our compiler to build it with the EAP modules we’ll be using. First edit /usr/src/freeradius/freeradius-1.1.3/debian/control and remove libssl-dev from Build-Conflicts: and add it to the end of Build-Depends: line. Your file should look like this:
Build-Depends: debhelper (>= 5), libltdl3-dev, libpam0g-dev, libmysqlclient15-dev | libmysqlclient-dev, libgdbm-dev, libldap2-dev, libsasl2-dev, libiodbc2-dev, libkrb5-dev, snmp, autotools-dev, dpatch (>= 2), libperl-dev, libtool, dpkg-dev (>= 1.13.19), libssl-dev
Build-Conflicts:
Next you’ll need to add descriptions for your EAP modules, so enter the following at the end of the file:
Package: freeradius-eaptls
Architecture: any
Depends: freeradius (= ${binary:Version}), ${shlibs:Depends}
Description: eap-tls module for FreeRADIUS server
Debian will not provide a binary version of the rlm_eap_tls.so library. This
module is required if you want to use EAP/TLS authentication, commonly used
for WiFi access points.
Package: freeradius-eappeap
Architecture: any
Depends: freeradius (= ${binary:Version}), ${shlibs:Depends}
Description: eap-peap module for FreeRADIUS server
Debian will not provide a binary version of the rlm_eap_peap.so library. This
module is required if you want to use EAP/PEAP authentication, commonly used
for WiFi access points.
Save and exit this file.
Next we’ll edit /usr/src/freeradius/freeradius-1.1.3/debian/rules. Find and comment our the “buildssl=” and “moduleslist=-“ lines and add the following lines:
buildssl=–without-rlm_otp –without-rlm_sql_postgresql –without-snmp
modulelist=krb5 ldap sql_mysql sql_iodbc eap_peap eap_tls
Save and exit.
Now enter the following commands:
echo “usr/lib/freeradius/rlm_eap_tls*.so” >/usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eaptls.install
echo “usr/lib/freeradius/rlm_eap_peap*.so” > /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eappeap.install
Next let’s create /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eaptls.postinst and enter the following:
#! /bin/sh
set -e
case "$1" in
configure)
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d freeradius restart
else
/etc/init.d/freeradius restart
fi
;;
abort-upgrade)
;;
abort-remove)
;;
abort-deconfigure)
;;
esac
#DEBHELPER#
Now we’ll create /usr/src/freeradius/freeradius-1.1.3/debian/freeradius-eappeap.postinst and add the following to it:
#! /bin/sh
set -e
case "$1" in
configure)
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d freeradius reload
else
/etc/init.d/freeradius reload
fi
;;
abort-upgrade)
;;
abort-remove)
;;
abort-deconfigure)
;;
esac
#DEBHELPER#
Now that the hard part is finished let’s compile our deb packages. Enter the following command:
cd /usr/src/freeradius/freeradius-1.1.3/
dpkg-buildpackage -rfakeroot -uc -us
If all went well you should now have several of .deb packages in /usr/src/freradius, so let’s install them by entering the following:
dpkg -i freeradius_1.1.3-3_i386.deb
dpkg -i freeradius-eaptls_1.1.3-3_i386.deb
dpkg -i freeradius-eappeap_1.1.3-3_i386.deb
Check to see if FreeRADIUS compiled and installed correctly by issues the following command:
ps aux | grep freeradius
And you should see something similar to this:
freerad 29998 0.0 0.8 44620 2224 ? Ssl 00:55 0:00 /usr/sbin/freeradius
If not start FreeRADIUS in debug mode as root and look for any clues to why things are not working properly:
freeradius –X
Also check /usr/lib/freeradius and ensure that the rlm_eap_peap-1.1.3.so and rlm_eap_tls-1.1.3.so modules exist.
Now to configure FreeRADIUS
First we’ll edit /etc/freeradius/radiusd.conf
NOTE: When editing the configuration files be sure that every open bracket ({) has a corresponding ending bracket (}) or you will break FreeRADIUS!
Find the mschap stanza under MODULES and configure it with the following parameters:
mschap {
authtype = MS-CHAP
use_mppe = yes
require_encryption = yes
require_strong = yes
}
Next verify the authorize stanza includes these parameters:
preprocess
mschap
suffix
eap
files
Now verify that the authenticate stanza is configured like this:
authenticate {
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
# Allow EAP authentication.
eap
}
Now we have to add a client to the clients.conf. By client we mean an authenticator such as an access point (AP) or a wireless controller. For this example we’ll use my Juniper SSG5’s address of 192.168.44.129. Add the following stanza to the clients.conf:
client 192.168.44.129 {
secret = test123
shortname = Juniper
}
Next we’ll configure our server to support PEAP by editing /etc/freeradius/eap.conf.
First change the default_eap_type in the eap stanza to look like this:
default_eap_type = peap
Because PEAP needs to support our example certificates uncomment the tls stanza as well as the following parameters.
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/cert-srv.pem
CA_file = ${raddbdir}/certs/demoCA/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
}
Next find and uncomment the peap stanza and the following parameter:
default_eap_type = mschapv2
Now add a test user in the /etc/freeradius/users file so we can test the system. Add the following:
“tobias” User-Password == “password123”
Restart FreeRADIUS with the following command:
/etc/init.d/freeradius restart
Now if you’ve done everything correctly you should be able to authenticate with your test user with the following command:
radtest tobias password123 localhost 0 testing123
You should see:
ending Access-Request of id 170 to 127.0.0.1 port 1812
User-Name = "tobias"
User-Password = "password123"
NAS-IP-Address = 255.255.255.255
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=170, length=20
At this point everything should be working, although you would have to export your CA’s certificate to your PEAP clients so they would trust the server certificate being used by FreeRADIUS. The certificates we are currently using are there only to test with and should not be used for production. Next I’ll explain how to setup your own certificate authority (CA) and create your own certificates.
First we’ll need to install OpenSSL and since we’ll need to generate some complex passwords we’ll also install PWGen the password generator.
apt-get install openssl pwgen
OpenSSL uses a defaults file, /etc/ssl/openssl.cnf, that we’ll backup and edit to save us some time when we start generating our certs.
cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.bak
Now edit /etc/ssl/openssl.cnf and find this line:
dir =./demoCA
and change to:
dir =/etc/freeradius/eap/eapCA
This is the location were I’ll be creating the new CA. You might want to look through the rest of the file and edit the defaults to your environment. Here are some of the changes that I made to my openssl.cnf.
-countryName_default = AU
+countryName_default = US
-stateOrProvinceName_default = Some-State
+stateOrProvinceName_default = Oregon
+localityName_default = Portland
-0.organizationName_default = Widget ltd
+0.organizationName_default = Fat of the LAN
Now create and change to the directory that all of our certificates and CA will exist:
mkdir /etc/freeradius/eap && cd /etc/freeradius/eap
We will use one of OpenSSL’s included scripts to generate our CA, but you’ll want to customize it a bit before we use it so we’ll make a copy of it in our certificate directory.
cp /usr/lib/ssl/misc/CA.pl /etc/freeradius/eap
Next we have to edit CA.pl to tell it where to create our CA. Open it and change the following line:
CATOP=./demoCA
to:
CATOP=/etc/freeradius/eap/eapCA
Your CA is at the heart of your certificate infrastructure so it is important to protect it once you’ve generated it as well as use a strong password for it. I’ll generate a nice random 25 character password with pwgen. Be sure to record this password as you’ll need it each time you sign a certificate.
pwgen 25 1
aem5xahheethohP5Woh5Eb3ph
Now let’s run the script from within the /etc/freeradius/eap directory.
cd /etc/freeradius/eap
./CA.pl –newca
Answer all of the questions based on your environment and use the password you just created when prompted. When the script finishes you’ll have your own CA in /etc/freeradius/eap/eapCA. The next thing we need to do is create a server certificate for FreeRADIUS and sign it with our new CA.
./CA.pl –newreq-nodes
We should now have a new key pair as well as a signing request ready to send to our CA.
A quick note on compatibility. If you plan to use any of these certificates on Windows clients you’ll need to add XP extensions to the certificates you generate. The xpextensions file is included with Debian’s FreeRADIUS packages and I’ll include it in the appendix for our non-Debian readers. Just make a copy of it in our certificate directory.
cp /usr/share/doc/freeradius/examples/xpextensions /etc/freeradius/eap
Now let’s use our CA key to sign the FreeRADIUS’ certificate request, entering the CA’s password when prompted:
./CA.pl –sign (Optionally add -extensions xpserver_ext -extfile /etc/freeradius/eap/xpextensions)
Now that all of the certificates we need are generated, we need to create a couple of files needed for keying material and tell FreeRADIUS to use the new certs. To create the dh and random files, issue the following command:
openssl dhparam -check -text -5 512 -out dh
dd if=/dev/urandom of=random count=2
chmod 640 random newcert.pem newkey.pem newreq.pem dh
Now open your /etc/freeradius/eap.conf file, find the tls stanza, and change to reflect the new certificates we created.
private_key_file = /etc/freeradius/eap/newkey.pem
certificate_file = /etc/freeradius/eap/newcert.pem
CA_file = /etc/freeradius/eap/eapCA/cacert.pem
dh_file = /etc/freeradius/eap/dh
random_file = /etc/freeradius/eap/random
And while we’re at it, uncomment the following lines:
fragment_size = 1024
include_length = yes
Restart FreeRADIUS and copy your CA’s certificate (/etc/freeradius/eap/eapCA/cacert.pem) to your clients. Configure your clients’ supplicant for your new PEAP enabled SSID, configure your AP to use 802.1x and your new FreeRADIUS server and you’re good to go!
If you are looking for more information on RADIUS, check out this book. It’s been extremely helpful thus far.
This question is so broad. It really depends on what you want to do, where your authentication data (e.g. users/passwords) is stored, what type of EAP methods you are going to use, etc.
However, the default FreeRADIUS configuration will work pretty well for most testing with minimal changes.
Start by editing the raddb/users file and add a new user to the top. The form should be like
username Cleartext-Password := "password"
Then you can use radtest or eapol_test to check to see if this is working.
When that works, you can edit the clients.conf file to add your wireless AP or controller.
You should then be able to connect from the wireless network.
However, this can be quite complicated and there are lots of things to go wrong along the way, so don't be discouraged if it doesn't work first time.
Always run the server with debugging on (radiusd -X) when testing, and read all the output. It will show you where things are failing.
There is a lot of information on the FreeRADIUS wiki, for example start with the Basic configuration HOWTO. There is also lots of good tutorial advice on Alan Dekok's page. Note that for wireless you do need to configure EAP.
Here is a step by step link that I used for my freeradius installation.
Freeradius 3 Ubuntu tutorial
If you're still having issues, get a vps that comes with radius installed