Categories
Interesting Stuff Security Sys Admin Web Apps

Chrome 70 vs Symantec Certificates

Chrome 70 is about to dis-trust a whole lot of certificates

So you paid lots of money for a “proper” certificate for your HTTPS website after Google gave non-HTTPS sites a hard time? Well, hopefully you aren’t still using an older Symantec issued certificate as Google (and others) is about to stop trusting those certificates.

Chrome version 70 is due for release in September for beta users and will NOT trust certificates issued before December 1 2017 from Symantec, Thawte, GeoTrust and RapidSSL.

This is obviously a big deal and as the Chrome browser release happens before your 12 month (or longer) cert will expire, means there’s work to do. While you’re revisiting the process of procuring another certificate, perhaps also have a think about why you might not be using the free service from Let’s Encrypt. That’s good enough for most websites unless you’re after one of the more fancy looking icons to show up in the browser for things like shopping carts.

Why is this happening?

The Certificate Authorities (aka CAs like Symantec) that are used to issue certificates that secure our web browser traffic MUST be absolutely trusted. Without that trust, the process fails and we might as well just create our own certificates. The reason why we don’t do that is that the browser vendors effectively have a list of those highly trusted CAs and each site’s cert must have a mathematical relationship to one of those.

In 2017 a number of issues were raised about how Symantec had been running one of their CAs (they have a few). Inconsistencies and bad-practice were highlighted such that both Mozilla (who have a list of the issues) and Google decided to implement a change in trust of certs issued by that CA.

Categories
How-To Sys Admin

Allowing SSH Key Based Logins from Another System

I have a Digital Ocean server that I SSH into from my laptop for mainly development purposes. But I also want to do scheduled downloads of the server backups from a server at home. So I need to SSH from a new machine to my server with no user prompt. Easy, but it always prompts me for a pass phrase and I have multiple keys in use on my home server.

While you could just copy your private keys from Client1 to Client2 in order to do this, it’s not a great thing to be doing security-wise. So let’s just not do that.

What you need to do is create a new key pair on Client2 (actually my home server) with,

ssh-keygen

When prompted, make sure you tell it to use a new key file if you have existing keys. If you don’t do that it’ll overwrite your old ones and you’ll be testing your recovery process. When prompted for a pass phrase, just leave it blank and hit Enter. While a pass phrase would be more secure, I want to use this SSH connection to automatically connect as part of a crontab job. So no one will be able to enter a pass phrase anyway.

So now we have a fresh keypair on Client2, say in a file called id_rsa_2. We need to get the public key id_rsa_2.pub to our remote server so it’ll trust us when we connect. We do that with a simple copy and append command,

cat ~/.ssh/id_rsa_2.pub | ssh <your-user>@<your-server> “cat >> ~/.ssh/authorized_keys”

When you run that command you’ll be prompted for your password as normal as we’re in the process of loading up the keys.

Now we have a new key pair and have copied the public key to the remote server so it trusts us when we connect. But if Client2 has multiple key pairs in use (i.e. we had to use id_rsa_2 as otherwise we would have overwritten existing keys), how does SSH on Client2 know which keys to use? By default it’ll always use the first key pair and not our new one.

The simple solution is to create a config file in Client2 called ~/.ssh/config and define a Host and which keys to use.

Host <your-server>
IdentityFile ~/.ssh/id_rsa_2

Now you should be able to SSH from your second machine to your remote server with new keys and by using the keys, not have to enter a password.