Posts Tagged SSL
Enabling Apache SSL and installing own certificates
Posted by MB in Uncategorized on April 23, 2013
This is for Ubuntu Server 12.04 64-bit.
The easiest way to activate Apache’s SSL is:
a2enmod ssl a2ensite default-ssl service apache2 restart
That’s all for the setup, now for installing the certificates. I am using certificates from StartSSL, so your installation may be slightly different.
Copy the unencrpyted SSL private key to /etc/ssl/private, chown it www-data:www-data, chmod it 700.
Find the line containing SSLCertificateKeyFile, uncomment it, and change it to point to your private key file, like so:
SSLCertificateKeyFile /etc/ssl/private/(your private key file)
Copy your public key to /etc/ssl/certs.
Change the SSLCertificateFile line to point to your public certificate, like so:
SSLCertificateFile /etc/ssl/certs/(your certificate file)
Find the following line and uncomment it:
SSLCACertificatePath /etc/ssl/certs/
That’s it.
StartSSL SSL Certificate on Synology NAS using subdomain
Posted by MB in Uncategorized on November 13, 2012
This will explain how to generate and install SSL certificates on your Synology NAS to get rid of the pesky SSL certificate errors. I’ll be explaining specifically how to generate and install from StartSSL, who gives out free SSL certificates.
First, you will need to own or control a domain name, and have a subdomain set up and CNAME pointed to your Synology NAS’s IP address. You can find a walkthrough on how to set that up by reading this article. If you are having trouble with certificate domain mismatches, make sure you have read this article first: Synology DiskStation on a subdomain with dynamic IP address.
Once that’s set up, head over to StartSSL and follow the steps outlined below to validate a domain name and generate an SSL certificate.
Validate a domain name
Select the Validations Wizard and choose type Domain Name Validation
Enter the domain name you wish to validate, and continue. You are validating only the base domain name.
Select an email address to which the validation code will be mailed to, and then continue.
Enter the validation code you received via email, and continue.
Generating your SSL certificate
After verifying your domain ownership, you can now generate the SSL certificate.
Select Certificates Wizard and choose Web Server SSL/TLS certificate, as in the image below.
Generate a private key by inputting a password of at least 10 characters, choosing your key length, and selecting SHA1.
On the next screen, you will be given your generated, encrypted, private key with instructions to save it to a file called ssl.key, and what to do with it. For now, just create a new text file on your desktop, call it “encrypted_ssl_key” (or whatever), and hang on to it for later. I’ll explain what to do with it in a few more steps.
Next, you’ll be prompted to add a verified domain to your SSL cert. Choose the previously validated base domain.
Next, you’ll be prompted to enter a subdomain to add to the certificate. This is where you enter your NAS’s subdomain. For example, if your root domain is example.com, and your NAS is accessible via myds.example.com, enter myds.
The ready processing certificate screen will show next, and should include both your base domain name and the subdomain, like this following image.
The following screen will appear, and prompt you to save the certificate, as well as the intermediate certificates, which you will need for the Synology NAS. Save the certificate in a file called ssl.crt as instructed. Hold on to both it, and the two downloaded intermediate certificates for the following steps.
Decrypt the private key
One more step before we install the certs onto the NAS box. Head over to the StartSSL toolbox and click on Decrypt Private Key.
In the top box, paste the saved encrypted private key that you generated and named “encrypted_ssl_key” (or whatever). In the Passphrase box, enter the 10-character-or-so password that you set on it, and click decrypt. Save the decrypted key to a file called ssl.key.
Installing the SSL certs
Now we’re ready to install the SSL certs onto the Synology NAS. Log in as admin and head to Control Panel > Web Services. Click the HTTP Service tab and click Import Certificate.
For each of the following select the corresponding files
Private Key: Your decrypted ssl.key file
Certificate: Your ssl.crt file
Intermediate certificate: The sub.class1.server.ca.pem intermediate certificate you downloaded.
(If you forgot to download the intermediate certificates, you can get them again by following this link.)
Click ok, and you should see Restarting Web Server, like so
Assuming all went well, you should be able to go to the subdomain and see a good SSL certificate lock icon, like so in Chrome
Questions, comments, or otherwise, please feel free to share them in the comments below. Thank you!
The importance of HTTPS login pages – Session hijacking fits in a pocket now
Posted by MB in Uncategorized on August 4, 2011
You should always prefer SSL-encrypted (HTTPS) login pages on sites over non-SSL (HTTP). Why?
Session hijacking is why.
First, let me [very briefly] explain the difference for the unfamiliar. SSL stands for Secure Sockets Layer and it’s the encrypted, secure version of HTTP, the protocol that loads web pages. Normal web access is over unencrypted HTTP (the http:// part of the web address) and secure access is over HTTPS (the https:// in front of the address bar). In the most basic terms, the extra ‘s’ stands for ‘secure’.
Some screenshots using Firefox:
Normal (unencrypted) session:
Secure (encrypted) session:
So why am I bringing this up? Because I got a chance to play with an app for Android that claimed to allow one to “capture” login sessions over wireless connections.
How does it work? Well, without going into too much detail you simply connect your Android-powered device running this application to a wireless network and it just sits and listens for login data and captures it. I sat down with the app a few minutes ago, put it on my network, and logged in to various sites. You know what? It worked. I was able to capture several logins in just a few minutes and log in to those sites from my mobile device without needing the password. Among those captured were my Facebook and Google login. Note that I had to disable HTTPS logins on Facebook to get it to capture. The encryption provided by HTTPS is enough to prevent this type of hijack from working.
That means that Joe Blow sitting two tables away from you at Starbucks with his phone in his pocket could be capturing your Facebook, Amazon, or other login credentials while you’re casually surfing the web and sipping coffee. This could also mean that your neighbors unsecured wireless network, which you’ve been casually using to avoid paying for your own, could be silently capturing your login details. This also means that if your own wireless network is unsecured, you’re leaving yourself open to this type of attack.
Note that this worked even though my network is WPA2 secured: I just had to enter the wireless key to connect to the network.
I’m not going to mention the name of the app, though it is available in the Android Market and does require a rooted phone, so if you want to go play with it you have to find it on your own. I’m also not encouraging stealing other people’s identities. As far as I know it’s a Federal crime. :) I’m writing this to make people aware that they should:
- Use HTTPS login pages whenever possible.
- Avoid using unsecured wireless networks.
- Secure your own wireless network and be aware of who you share the key with.
- Change your own wireless key from time to time if you share it.
Have a nice day :) As always, feel free to share your comments below!
Google Talk via Empathy
Posted by MB in Uncategorized on May 24, 2011
Google Talk via Empathy is another IM protocol connection that needs a little tweaking with the settings to get to work. Here’s the run-down on what needs to be set:
Go to Edit > Accounts, select Add then Google Talk.
Fill in the name, optionally select remeber password and enter your password, then tick down the Advanced arrow and …
Check Ignore SSL Certificate Errors
Under Override Server Settings
- Server: talk.google.com
- Port: 5223
Check Use Old SSL
You should be able to connect now.
Questions, comments, and feedback are welcome, as always. I’m sure some of these settings are not needed or can be simplified, so I would appreciate any feedback anyone can share. Thank you!
Ubuntu, Apache, VirtualHosts, and SSL – part 2
Posted by MB in Uncategorized on May 18, 2011
In my first post about Ubuntu, Apache, VirtualHosts, and SSL I covered generating self-signed certificates and implementing them for Apache VirtualHosts. What I didn’t cover was — if you implemented this without a correct base configuration — you’d end up with some unexpected results if you tried to visit your base domain over SSL.
It’s simple to resolve this. First, edit /etc/apache2/ports.conf and modify as follows:
# If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. + NameVirtualHost *:443 Listen 443
If you were reading closely, you know what to do next. Modify sites-available/default-ssl file and change the directive as follows:
Now, restart apache:
/etc/init.d/apache2 reload
Your base SSL domain will now display the expected DocumentRoot, but the certificate will contain the URL localhost.localdomain. To fix this run, as root:
make-ssl-cert generate-default-snakeoil --force-overwrite
— From /usr/share/doc/apache2.2-common/README.Debian.gz
If you install the ssl-cert package, a self-signed certificate will be
automatically created using the hostname currently configured on your computer.
You can recreate that certificate (e.g. after you have changed /etc/hosts or
DNS to give the correct hostname) as user root with:
make-ssl-cert generate-default-snakeoil –force-overwrite
—
Questions, comments, and feedback regarding this guide and welcome!
Forcing SSL for phpMyAdmin
Posted by MB in Uncategorized on May 16, 2011
After configuring WordPress to force SSL in the administration area, I was in phpMyAdmin and realized that it’s also not configured to do the same by default.
From the phpMyAdmin Wiki, add the following line at the end of your /etc/phpmyadmin/config.inc.php file
$cfg['ForceSSL'] = TRUE;
This will cause sessions to force SSL.
If you’re having issues making this work for you, check out my article involving Apache and SSL.
Questions, comments, and feedback are welcome.
Forcing the WordPress administration over SSL
Posted by MB in Uncategorized on May 14, 2011
From the WordPress administration over SSL guide, add the following directive to your wp-config.php file:
define('FORCE_SSL_ADMIN', true);
This will cause logins and admin pages to force SSL sessions.
If you’re having issues making this work for you, check out my article involving Apache and SSL.
Questions, comments, and feedback are welcome.
Ubuntu, Apache, VirtualHosts, and SSL
Posted by MB in Uncategorized on May 4, 2011
The goal of this guide is to provide you with an Apache SSL configuration with a unique self-signed certificate for each VirtualHost.
These self-signed certificates are not intended for e-commerce or public-facing web sites. Rather, they are intended for SSL encryption of administration areas on personal websites or administration programs that have HTTP interfaces. Of course, if you have a commercially-signed certificate, you can skip the certificate-generation part of the guide, and proceed to implementing it in a VirtualHost configuration.
Written for Apache on Ubuntu Server 10.04.
First, install the base Apache SSL certificate and enable the Apache SSL module
sudo apt-get install ssl-cert
a2enmod ssl
This installs a base SSL certificate and a generic ‘default-ssl’ site configuration. We will be generating per-domain self-signed certificates later. We will also not be using the ‘default-ssl’ site configuration.
Generating Certificates
Generate a hostname-specfic SSL certificate by following these instructions quoted
— From /usr/share/doc/apache2.2-common/README.Debian.gz
To create more certificates with different host names, you can use
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert-file.crt
This will ask you for the hostname and place both SSL key and certificate in
the file /path/to/cert-file.crt . Use this file with the SSLCertificateFile
directive in the apache config (you don’t need the SSLCertificateKeyFile in
this case as it also contains the key). The file /path/to/cert-file.crt should
only be readable by root. A good directory to use for the additional
certificates/keys is /etc/ssl/private .
—
Example:
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/private/example.com.crt
Implementation
Now that the key is generated, we’re going to create an Apache VirtualHost configuration for SSL connection. Chdir to /etc/apache2/sites-available and copy (for example) example.com.conf to example.com-ssl.conf
Next, edit the example.com-ssl.conf file and make the following changes:
Example:
...
* Change the defined port number in the tag from 80 to 443
Example:
... ...
* At the end of the file, after the tag, add
...
* Within the tag, add the following directives:
SSLEngine On # The following should point to your SSL cert file in /etc/ssl/private SSLCertificateFile /etc/ssl/private/example.com.crt
— From /etc/apache2/sites-available/default-ssl
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
—
* Add the SSL workaround for MSIE in your section as follows:
BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
— /usr/share/doc/apache2.2-common/README.Debian.gz
SSL workaround for MSIE
———————–
The SSL workaround for MS Internet Explorer needs to be added to your SSL
VirtualHost section (it was previously in ssl.conf but caused keepalive to be
disabled even for non-SSL connections):
BrowserMatch “MSIE [2-6]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
BrowserMatch “MSIE [17-9]” ssl-unclean-shutdown
The default SSL virtual host in /etc/apache2/sites-available/default-ssl
already contains this workaround.
—
Lastly, enable the newly-created site and reload apache:
a2ensite example.com-ssl.conf
Enabling site example.com-ssl.conf.
Run '/etc/init.d/apache2 reload' to activate new configuration!
(This creates the symlink from /etc/apache2/sites-enabled to your config file in /etc/apache2/sites-available – you can also create it manually if your configuration requires it)
/etc/init.d/apache2 reload
* Reloading web server config apache2 [ OK ]
Of course, make sure after all of this that your firewall isn’t blocking port 443.
Questions, comments, and feedback regarding this guide and welcome!
PGP/GPG Keys in Ubuntu Gnome the easy way – Part 2
Posted by MB in Uncategorized on April 27, 2011
In part 1, I explained how to generate and manage your encryption keys in GNOME. Now I’ll explain how to use your keys to easily encrypt your email. I’m going to only address doing this in Evolution (the default email manager in GNOME). You can access the Evolution email account settings by going to System > Preferences > Email settings [Natty/Unity: System Settings > Email], and I’ll assume that Evolution is already set up for your email account.
Integration into Evolution is painlessly simple: You just need the Key ID of your key.
Go to System > Preferences > Passwords and Encryption Keys and look in the column under Key ID. The Key ID is hex, so it only uses the characters 0-9 and A-F.
Once you have the Key ID, start Evolution and go to Edit > Preferences > Mail Accounts and click your mail account and click edit. Then, go to the Security tab and enter your Key ID in the PGP/GPG Key ID field.
That’s it. Now whenever you compose a message, you’ll see the PGP menu which will allow you to sign and/or encrypt your email messages, and in the reading pane you will see the status of signed/encrypted messages sent to you.
Questions, comments, and feedback to this are welcome, as always.
Empathy gives ‘untrusted connection’ certificate warning when connecting to Facebook via XMPP
Posted by MB in Uncategorized on April 12, 2011
Empathy users may have experienced a rather annoying problem if connecting to Facebook via XMPP using Empathy. This problem may affect other services too, such as Gwibber, but I’m not using Gwibber — so I’m only writing about this.
When trying to connect, you’ll receive a message like the following:
Even if you check “Remember this choice for future connections”, you’ll still get it next time you launch Emapthy.
It seems the root cause is a certificate not being installed in ca-certificates during installation. The original issue and solution are described in Launchpad bug #746973, and is root caused in Launchpad bug #742889.
I’ve rewritten the solution here with some adjustments to the steps for clarity and where instructions were incomplete or needed explanation.
Start by opening Firefox to get the correct certificate out of the certificate store.
In Firefox, go to edit > preferences > advanced > encryption > view certificates > authorities
Scroll down to DigiCert Inc, and find “DigiCert High Assurance CA-3”
Click “Export” and save the file somewhere you can find it later.
I called it DigiCertHighAssuranceCA-3.crt (you will probably have to add the extension, which is important).
It automatically exports in PEM (X.509) format, which is what we need.
Verify by opening a terminal and typing
file DigiCertHighAssuranceCA-3.crt
You should get:
DigiCertHighAssuranceCA-3.crt: PEM certificate
Now, become root (sudo su) and execute the following commands to move the file to the ca-certificates installation source:
mv DigiCertHighAssuranceCA-3.crt /usr/share/ca-certificates/mozilla chown root:root /usr/share/ca-certificates/mozilla/DigiCertHighAssuranceCA-3.crt dpkg-reconfigure ca-certificates
Select “yes”, then scroll down the list and place a mark (using the space bar) next to the certificate we just added. Press the TAB key to move the cursor to OK then press space again to confirm.
You will likely see output similiar to the following:
Updating certificates in /etc/ssl/certs... WARNING: Skipping duplicate certificate brasil.gov.br.pem WARNING: Skipping duplicate certificate Go_Daddy_Class_2_CA.pem 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... updating keystore /etc/ssl/certs/java/cacerts... added: /etc/ssl/certs/DigiCertHighAssuranceCA-3.pem done. done.
Confirm that it’s fixed by exiting empathy if you had it opened (Chat > Quit) waiting a moment or two and then restarting it. You should automatically be signed into Facebook XMPP without the certificate warning.
Questions, comments, and feedback about this are welcome and appreciated.
