Google Chrome, the most popular browser on the planet, has just rolled out an update of version 68 and it’s one of the most crucial Chrome updates in recent times. The reason behind this is the decision of Google to mark all HTTP sites as ‘Not Secure.‘ Yes, you read it right. All websites serving content over HTTP will now be marked with a ‘Not Secure’ warning.
A comprehensive list of country codes for use in generating a Certificate Signing Request
Now that Trustico has screwed the pooch and ruined online CSR generators for everyone, people have to resort to generation Certificate Signing Requests on the servers they want to encrypt. And while this is, for all intents and purposes, a good thing for the overall security of the web, it does eliminate a certain convenience factor.
SSL certificates have several different file formats. What works for one server might not work for another. Fortunately, I’m here to help you figure out how to turn your SSL certificate files into a .PEM file.
A .PEM file is sometimes referred to as a concatenated certificate container file. Concatenated is a five dollar word if I’ve ever heard one. But don’t let it distract you, all it means is that all of the certificates in the chain need to be combined into a single file.
It’s always amazed me that something as complicated as encrypting a connection between a web server and a client can be facilitated by a file that you copy and pasted into a text editor. Think about that for a second the next time your IT guys complains to you about the certificate file being the wrong format. You literally train a chimpanzee to concatenate a certificate file.
How to Concatenate your entire SSL certificate trust chain into a .PEM file
Ok, stay with me because this is practically rocket science. Take the SSL certificate that your CA sent you and open it in a text editor.
Ok, a quick aside, do not use Microsoft Word, Word Processor or any other program that autocorrects. Use Notepad or whatever hemp-wearing, literary safe space that Apple offers as Notepad’s alternative.
Now, take the SSL certificate you just opened in Notepad, copy and paste the whole thing (even the Begin and End certificate prompt at the five dashes on either side of them) into a new Notepad document.
If your SSL certificate came with an intermediate, download it, open it in notepad and do the same thing, even down to the prompts and dashes.
Now, finally, download the root certificate and follow the same procedure, opening it in notepad, copying the entire file (dashes and all) and pasting it in the new text file with the other certificates.
Once again, save the file as “Something_You’ll_Remember.pem”
How to Concatenate your Private key and Trust Chain
Once again, the method is the same for this procedure – copy/pasting certificate files in the correct order into a new notepad document – but adding the Private Key means you’ll now potentially be combining four files.
The private key goes first, then you can revert to the order we have used in the other procedures: End User Cert, Intermediate, Root.
DigiCert will now allow Symantec CA customers to renew up to seven months early
Though I’m tempted to start this post by saying that, “if you haven’t been living under a rock you likely know about the Symantec-Google distrust,” I realize for the majority of people – those who don’t work in cybersecurity or sell cybersecurity products – that isn’t true. This whole situation with Symantec has been a huge deal within a certain space, but outside of it – there hasn’t been much attention.
That’s probably owed to the fact that digital certificates are exceedingly boring.
For many people, the first they had heard that Google was distrusting Symantec CA Brand (Symantec, RapidSSL, GeoTrust & Thawte) SSL certificates was a couple weeks ago when their website starting getting browser warnings. So let’s talk about how we got here and how DigiCert is now prepared to make this right for Symantec customers.
Why is Google distrusting Symantec CA SSL certificates?
Pull up a chair and let me tell you about a time before certificate transparency and CAA records, when the digital certificate landscape was like the wild, wild west. The time was 2015, and Google came to Symantec with some issuance problems. Unfortunately, Symantec’s response didn’t satisfy Google and when some more mis-issuances came to light, followed by evidence of lax oversight of regional authorities that were handling validation in certain geographical locations, Google and the other browsers decided they just couldn’t trust Symantec’s PKI anymore and would need to distrust every SSL certificate that had been issued from it.
Now, there are three ways to look at this. The first is the browsers’ perspective. Symantec had demonstrated across several situations that it didn’t have proper oversight over its issuance practices and that created a degree of risk with regard to its PKI and the possibility that other mis-issuances had gone unreported. Ergo, the entire PKI needs to be distrusted. Also, an example needs to be made out of a big CA.
Symantec, on the other hand, pointed out the scale of the reported issues was minute. 33 mis-issued test certificates, by Symantec’s count. Zero real-world harm. It’s like finding a small scratch on a car’s fender and then arguing that by virtue of the scratch, we can no longer trust you take care of the rest of the car, including what’s under the hood, so it needs to come off the road. It seems excessive because it is a little excessive.
Then there’s the third perspective: everyone else’s. That is, “a bunch of squabbling nerds drinking designer juice in Silicon Valley just cost me time and money.”
In the real world, nobody cares about a bunch of test certificates or the conduct of a regional authority in a distant time zone, they care that the product they paid for isn’t functioning like it’s supposed to. It doesn’t matter who’s fault it is, or why. What matters is that we fix this with minimal friction.
DigiCert is lending a hand to Symantec customers
As part of Symantec’s agreement with Google and the other browsers, DigiCert acquired the Symantec CA last Fall and began issuing digital certificates for Symantec in December. Since then, DigiCert has been steadily working to replace the SSL certificates that Google is eventually going to distrust.
The first group of certificates was distrusted a couple weeks ago with the latest release of Chrome. That leaves one final group of SSL certificates that will be distrusted on October 23rd.
Unfortunately, for that group of customers, many were getting the absolute $#%& end of the stick because their certificates are set to expire weeks after they re-issue them. In other words, because it’s too early to renew, they would be stuck re-issuing and re-installing, and then doing much the same thing a couple months later when they renewed.
Fortunately, DigiCert is giving you a pass. The renewal window for Symantec CA SSL certificates issued before December 1, 2017 is now seven months, meaning you can renew today and just be done with this entire distrust thing.
Best of all, DigiCert will round up the time you have remaining, up to seven months. So if you renew with six and a half months to go, DigiCert will issue you a certificate with seven months carried over. Unfortunately, because of the CAB Forum baseline requirements, this is only good for one year renewals, owing to the 825 day max validity.
But still, if you’re a Symantec CA customer and you need to re-issue before the October final distrust, DigiCert has a way for you to renew now and put all of this ugliness behind you.
The General Data Protection Regulation requires your action
The European Union’s new fangled General Data Protection Regulation (GDPR) becomes enforceable on May 25th. It’s a well-intentioned document, but like anything else that is written by politicians at a big government level—it’s fairly ham-fisted in many areas.
Part of the problem is that it requires you to have a knowledge of previous European legal frameworks like the ePrivacy directive, in addition to knowing some European case law. For American businesses navigating this can be tricky. Especially when you factor in that European legalese is much different than the legal writing in this country. It’s written like you need to be wearing a powdered wig to make complete sense of it. It can all be a bit jarring. It can also be lethal if you’re a small company and you run afoul of the GDPR.
Penalties for violations start at 10-million euros or 2% of your total revenue—whatever’s bigger. More egregious issues will be met with fines of 20-million euros or 4% of total revenue.
If Facebook had its Cambridge Analytica after May 25th, in Europe, it would be looking at a fine worth more than 7 billion dollars.
Those are pretty high stakes. And as you’re about to find out, compliance with the GDPR isn’t just an issue for European businesses. US businesses might be in for some trouble, too.
Here are five things US businesses need to do before May 25.
1 – Figure out whether you need to be GDPR compliant
This sounds dumb, but it’s really not. In my experience, one of the biggest reasons for non-compliance is simple ignorance. The violations occurred because the party in question had no idea they needed to comply with something in the first place. This is especially true for smaller businesses, which is made even more dangerous by the penalties that can be levied. For small businesses, the GDPR can present existential crises. One fine and you’re down for the count.
The misnomer is that only businesses in Europe need to comply with the GDPR. That is patently false. Someone said that to me the other day, actually. “But Carl, we don’t need to do anything for GDPR because we’re not in Europe. I learned real close to him, maybe an inch from his face and snarled at him, “I’ll get you. And it will look like an accident.”
Anyway, if you do any business in Europe, you need to be GDPR compliant. Now, what might you ask does, “doing business” entail? That’s a question that’s still being debated. It’s written a bit vaguely. But for our purposes, if you market products in Europe, accept European currencies or have any sort of physical presence in the European Economic Area, you are doing business in Europe.
Now, if you’re a dentist in Memphis or you run a company that rents out those inflatable bouncy houses in the suburbs of Toledo you probably don’t need to be GDPR compliant. But if your company or organization make any attempt to market or sell in the EEA, you need to comply.
2 – Know your role
Once you’ve decided whether or not you need to comply with the GDPR (and assuming you do, as you probably would’ve stopped reading by now otherwise) it’s time to figure out the role you’re serving in the data ecosystem. There are three basic roles:
Data Subject – The individual who’s data is being collected
Data Processor – The party that is processing data on behalf of someone else
Data Controller – The party that controls the personal data and determines what it’s processed for
Now, there’s a very simple litmus test for whether you’re a processor or a controller: do you store the information on your servers? If you do, you’re a controller. If you just process what someone else sends you and store nothing, then you’re a processor. Remember controllers can process. But processors don’t control.
It’s extremely important that you figure out your role. And that you’re correct about it, too. You don’t want to find out the hard way that you’ve been mischaracterizing yourself. There’s nothing worse than getting knee-capped because you complied with the wrong set of rules.
3 – Map everything
This is actually a lot easier than it sounds… for most people. If your web presence is a hydra with various public-facing domains and massive digital infrastructure, this could be a challenge. But you should have the resources.
SMBs should have no problem though. Here’s how you do it:
Crawl your website looking for every single touchpoint that collects personal data.
Identify what information is being collected at those touchpoints
Identify what the information you’re collecting is being used for in each instance
Figure out where you’re storing this information
Figure out what a customer would need to do to modify or delete it
Now, and here’s the most important part, write that stuff down. Document everything. It’s crucial that you know exactly what is being collected and where. As well as why. This is also a good time to identify any superfluous data that you’re collecting and stop. Because the GDPR is pretty clear about only taking what is needed, and not hanging on to it for too long afterward. I realize that sounds like something Pocahontas would have said to John Smith but it’s still good advice.
4 – Figure out your Legal Bases for processing
There are six justifiable legal bases for processing information under the GDPR, though it’s clear from a lot of the guidance and from the document itself that the GDPR favors consent over the other five. The conditions for obtaining consent are rigidly defined and extremely, well, rigid. Consent must be freely given, the data subject must be well-informed and given an obvious choice to opt out. You can’t opt someone in by having a box checked by default. And for emails, you need a double opt-in. Additionally, the data subject maintains certain rights over the information when consent is used as the legal basis for processing. Consent also expires. The GDPR isn’t explicit about its shelf life, but you’re ideally supposed to re-engage and re-permission at regular intervals.
That makes marketers sad.
Fortunately, there are ways to get around using consent as your legal basis. For instance, if you’re running an e-commerce website, you can claim legitimate interests as your basis for processing some data, specifically for the purposes of cart abandonment and email marketing. Additionally, many organizations are processing information as part of the terms of a contract. That’s a justifiable legal basis, too. Before you charge headfirst into using consent as your legal basis, explore the other five to see if one of those might work better.
5 – Get EU-US Privacy Shield certified
The GDPR bans cross-border data transfers except into jurisdictions that provide “adequate” data protection. In this case, we’re not referring to technical safeguards, but rather legal ones. Unfortunately, the United States has not been deemed adequate.
So instead, what you’ll need to do is get EU-US Privacy Shield certified. Basically, you need to perform a self-assessment similar to the one we discussed earlier. You need to lay out what data you’re collecting and what you’re doing with it, then you need to agree to follow the principles laid forth in the EU-US Privacy Shield framework. Finally, you’ll have to get a corporate officer to sign it, pay some fees (depending on your size and revenue, upwards of several thousand dollars) and submit your self-certification to the Department of Commerce. You have to re-certify every year, too, and once you commit to the Privacy Shield policy, the FTC or the Department of Transportation, whoever oversees you, can legally fine and penalize you for non-compliance.
If you think #5 sucks, you’re not alone. And while I like to avoid politics like the plague, this is all Donald Trump’s fault. That’s not hyperbole, it’s a factual statement. You see it was President Trump, who ran on an anti-immigration platform, that signed an executive order his first week in office that tried to crack down on Sanctuary Cities. Keep in mind, this executive order was meant to target Hispanics (and probably Muslims, too). It included a line that said:
Agencies shall, to the extent consistent with applicable law, ensure that their privacy policies exclude persons who are not United States citizens or lawful permanent residents from the protections of the Privacy Act regarding personally identifiable information.
Basically, that meant that the digital privacy rights afforded to American citizens do not extend to non-citizens. Foreigners have no right to digital privacy in the US. As the European Commission was quick to point out, a point which the Trump administration clearly missed, that this executive order also strips digital privacy rights from Europeans. Thus the US does not afford “adequate” data protection for EU companies to comfortably transfer data into its borders. Congress has attempted to rectify this situation by passing the US Judicial Redress Act, which once against extends the benefits of the US Privacy Act to Europeans. That’s kind of racist when you think about it, but let’s not. Instead, just remember who to thank when you have to pony up a few grand each year just so you can continue business as usual with your European partners.
I hope this helps you out, and as always leave any comments or questions below.
Learning to use Java Keytool Keystore – the basics
Java Keytool is management platform for private keys and certificates, providing users with the ability to manage their public/private key pairs and certificates in addition to caching certificates. The keys and certificates are stored in what Java has cleverly named, a “keystore.”
Outdated SSL implementations are the computing equivalent of spoiled milk
By now you’ve probably heard the exciting news that TLS 1.3 has been released! Oh, you hadn’t? I guess it’s easy to forget that outside of the handful of people who design, sell, market or deploy TLS on a large scale—nobody cares. That may include you. In fact, you’re probably only here because something broke, or you got an error or you’re my boss and you’re checking to make sure I haven’t been sowing insurrection on the internet again.
Well listen up, as we continue to refine the TLS protocol and release new versions it’s important that you occasionally go through your implementations and disable old and outmoded versions. Consider it like digital spring cleaning.
Hypothetically, say I didn’t disable old SSL/TLS versions…
You like to live dangerously, do ya? If the internet’s Do-no-Evil overlord, Google, finds out that your server still supports TLS 1.0 it will dispatch its agents to literally drag you out of your bed and summarily execute you in the street. And that’s just for TLS 1.0, heaven forbid your server still supports SSL 3.0, Google may end your entire line, Game of Thrones style—which is usually gory. [Editor’s Note: Carl, this is an article about disabling BROWSER support…]
Fortunately, you’re not dealing with this issue server-side. That’s a different article. You’re just worried about how to handle things from the browser side. Great question!
Why do I need to disable browser support for SSL 3.0?
POODLES! No seriously, there’s a threat called POODLE, Padding Oracle On Downgraded Legacy Encryption, which granted POODLE is the acronym, but nothing makes a legitimate threat sound less important than naming it after a bourgeois French dog with a bad haircut.
Anyway, POODLE is serious. It allows attackers to extract data from a secure connection by forcing it to downgrade to outdated protocols. To avoid this you need to disable support for SSL entirely (and TLS 1.0, too).
So here’s how to disable browser support for SSL 3.0…
How to disable SSL V3 in Internet Explorer
Open Internet Explorer, click the Gear, the select Internet Options
Select the Advanced Tab, scroll down to the Security section
In the Security section, locate the Use SSL and Use TLS options, uncheck SSL 2.0, 3.0 and TLS 1.1
Click apply, then OK
How to disable SSL V3 in Firefox
Open Firefox, in the address bar type “about:config”
In the search field, type “TLS”
Double-click on security.tls.version.min
Type 1.1 in the Enter Integer Value window
How to disable SSL V3 in Chrome
Google disabled support for SSL 3.0 after version 38. And rather than give you years old instructions on how to disable SSL 3.0 in version 38 or earlier, I’m going to give you a piece of invaluable advice:
Writing a comprehensive guide to OpenSSL commands seems an odd job to give an aging man who, up until recently, thought servers could only be found hoofing it from kitchen to table in a chain restaurant. Probably one that can’t attract millennial customers. Seriously. Millenials are the worst thing to ever happen to Applebee’s. But that’s another discussion for another time.
Today, we’re here to discuss OpenSSL command lines.
What is OpenSSL?
OpenSSL is a software library, a cryptography library to be exact. It’s a robust, full-featured toolkit for the open-source implementation of the SSL and TLS protocols. It includes tools for generating Certificate Signing Requests and Private Keys. It’s written in the programming language, C, though there are wrappers available for a wide range of computer languages. About two-thirds of all web servers are using OpenSSL.
Why do I need to learn OpenSSL commands?
Now, I know what you’re asking: “can’t I just generate a private key and a CSR in my browser with an online tool?” No. No you may not. Google recently buried Mr. Trustico for that. And Google hasn’t pulled a wet job since it whacked Jeeves. So that means we need to learn some command lines. That’s right, today we’re going to forget some relevant information so we can make space in our brains for some random strings of text that a computer will understand.
So say goodbye to the Pythagorean theorem and say hello to… this.
Checking your OpenSSL Version
Sometimes you’ll need to identify which version of OpenSSL is being used on a given server. And even if you already know, sometimes it’s nice just to ask the server a few questions about itself before you start bossing it around. That’s called foreplay.
Anyway, figuring out what version of OpenSSL you’re working with lets you know about what it’s compatible with. This will be even more important when TLS 1.3 rolls out, as you’ll need to make sure your OpenSSL implementation supports it.
Use the following command line check OpenSSL Version:
openssl version -a
OpenSSL Commands Lines for Generating a CSR
You can’t get an SSL certificate issued without a CSR. Fortunately, OpenSSL makes it easy to complete one. Sort of. Your CSR contains the Common Name of the website you want to secure, along with other identifying information about the company or organization acquiring the certificate. It also contains your public key. But to generate a public key, and by extension a CSR, you need to first generate a private key.
Generating a Private Key with OpenSSL
Now let’s get into generating your super secret private key (relax, it’s not as cool as it sounds – it’s really just a 2,048-bit string of random numbers).
Good luck sticking that in a keyhole.
Anyway, you’re going to need to determine a few things about your Private Key before you can generate it. You need to:
Pick a Key Algorithm – From a compatibility standpoint we suggest RSA. Other options are available if you need them though.
Pick a Key Size – Again, we recommend going with 2048-bit RSA
Pick a Password – This is optional, if you decide to use one you’ll need to remember your password anytime you want to use your private key.
Now that you’ve decided, let’s get to the command lines.
To generate a 2048-bit RSA key, use this:
openssl genrsa -out yourdomain.key 2048
To view the raw, encoded contents of the key, use this:
To decode the private key, use this:
openssl rsa -text -in yourdomain.key -noout
Extracting your Public Key using OpenSSL
Your private key is actually what spawns your public key in a scientific process called budding. [Editor’s Note: That’s not true.] Ok, ok, the Private Key file contains the Public Key too, if you ever need to extract it, use this:
The server will respond by asking you a series of questions. Your answers to these questions will be embedded in your CSR. So answer them correctly.
Country Name: (2 Letter Code) – Enter your Country Code
State or Province (full name) – Enter your State/Province
Locality Name – Enter your city
Organization Name – Enter the name of your company
Organization Unit – What department are you forced to do team-building with?
Common Name – Enter your Fully-Qualified Domain Name
Email Address – Enter your email address
A challenge password – Skip this, press enter
An optional company name – Skip this, press enter
When you’re done press enter.
Creating your CSR with a single OpenSSL command
This is for the advanced users. If you want to generate a private key and a CSR simultaneously then you can use the following command. Just remember to saw the placeholder information with your information. If you copy-paste this command directly you’re not going to get a certificate.
Verifying the Contents of your CSR with OpenSSL commands
Sometimes you may want to double-check whether the information contained in your CSR is correct. Maybe someone else at your company did the CSR and you need to double-check their work because they are an idiot. Or maybe you went shopping online a little inebriated and ordered some SSL certificates and now you need to make sure you got the information correct. Whatever your reason, here’s how to check the contents of your CSR:
Exporting your CSR to send to a CA with OpenSSL commands
You need to send your CSR to your Certificate Authority in the PEM file format. That means using a command line to get the raw output of the CSR, then copying it in to a text editor and then either pasting it in your CA’s order form or getting it to them by some other means.
Anyway, here’s the command line to get the raw output from your CSR:
Viewing your SSL Certificate information with OpenSSL commands
To view the contents of any X.509 certificate use the following command:
openssl x509 -text -in yourdomain.crt -noout
Verifying Keys match with OpenSSL commands
Sometimes you need to make sure that your key pairs match. Using the following commands generates a hash of the output for your CSR, Private Key and Certificate. You need to compare the values, and if they match you know that your key pairs match, too.
SSL is available with 128-bit SSL or 256-bit SSL encryption, actual strength may vary
When you shop for SSL certificates, you’ll see options for 128-bit SSL or 256-bit SSL encryption strength. Which is better?
The bigger one!
Stay cautious, my friends… [Editor’s Note: Sit back down, Carl. You’re not done…]
Ok, ok. There’s a little more to this than just bigger is better. And I hate to break this to everyone but a lot of this discussion about 128 bit vs 256 bit encryptionthat gets done is more just slick marketing than an objective representation of factual information.
Here’s the thing, your SSL certificate isn’t the only that that has an impact on your actual encryption strength. Period.
Anyone who tells you different deserves a swift kick in the shin.
Let’s start from the top…
First, some background on Encryption
Around 1990, back when people still had social skills, e-commerce emerged as the internet started to facilitate business. Unfortunately, the internet was designed in a way that communication takes place in plaintext unless encrypted, so the nerds of the day set to work devising a mean to encrypt communication.
Now, at the outset information was sent over the internet using Data Encryption Standard or DES. That method used a 56-bit key for symmetric encryption. Symmetric encryption is when both keys are the same and can both encrypt and decrypt the communication.
Unfortunately, DES proved susceptible to hacking attempts so a new method was created, AES or Advanced Encryption Standard. This facilitated more robust encryption.
Cutting through the Marketing Speak
128 bit SSL encryption is a protocol that uses the key that is 128 bit in length to encrypt the data whereas 256 bit SSL encryption uses 256 bit key.
A lot of companies will try to sell you a 128 bit SSL certificate or a 256 bit SSL certificate. This is, at best, misleading and at worst it’s outright lies. Your SSL certificate actually has little bearing on the actual strength of your encryption. That relies entirely on your server configuration and the capabilities of the browser connecting with it.
To put it another way, purchasing a 256-bit SSL certificate does not mean your website will be using 256-bit symmetric encryption for every connection. In fact, depending on the technology in place you could be looking at as little as 40-bits of protection. You’ll have the capability to facilitate encrypted connections up to 256-bits, but there are a lot more variables in this equations than just your certificate.
So, when encryption strength is mentioned in SSL marketing what you’re actually referring to is the length of the key used for cryptographic operations. The key itself may be 256-bits, which is actually how resistant something is to guessing, but the actual strength of the encryption may be much less as a result of a range of factors.
How long would it take to crack my cryptographic key?
Time to Crack
1.02 x 1018 years
1.872 x 1037 years
3.31 x 1056 years
What should I pick?
With symmetric encryption, we use slightly smaller key sizes that are, in all honesty, slightly less secure as a trade-off for better performance. Frankly, either is probably fine given that neither will be crackable, in practice, until quantum computers advance a little bit more. Still, within the AES encryption algorithm, it’s better to go with the 256-bit key given that it is substantially more difficult to crack.
However, once again, remember that your key length is not a true indicator of your actual encryption strength. 256-bit SSL may not always facilitate 256-bit encryption in practice.
SSL for Subdomains
Secure main website and unlimited subdomains on the multiple servers with one RapidSSL Wildcard Certificate.