http vs. https
HTTP is no longer considered a safe encryption mode on the web. The current standard is HTTPS.
The simplest way to understand is this: pretty much the entire cyber-criminal world knows the hacking methods to outdated HTTP coding.
So what to do?
The mechanism of SSL certification has two important functions: Authentication and Encryption.
As a means to authorize a connection, the SSL certificate holds information about the business (Authentication), website or person you are connecting to, and is also a means to verify that identity through a third-party…scrambled and re-assembled via Encryption.
If you wish to see this in action, look at the URL of this web page in the address bar of your browser, and alongside the text, just on the left, you should see a small green padlock that identifies that this is a secure SSL-certificated site.
Do you see it?
Clicking on the padlock will tell you that the connection is secure and allow you to reveal what information the certificate has. That will include the users of the certificate, and the SSL provider that bestowed authorization.
A site at risk looks like this:
In addition to authority and verification, the SSL certificate also includes a means to encrypt traffic between the user’s computer and the website. Without this encryption, sensitive information like passwords could potentially be compromised by a nefarious party intercepting the data traffic flowing between the client computer and the web server.
Root certificate
In cryptography and computer security, a Root Certificate (RC) is a public key certificate that identifies a Root Certificate Authority (CA). Root Certificates are self-signed and form the basis of an X.509-based Public Key Infrastructure (PKI), which matches the Authority Key Identifier with Subject Key Identifier. In some cases if there is no Authority Key identifier, then the Issuer string should match with subject string (RFC5280). For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature depend on a set of root certificates that align.
A CA can issue multiple certificates in the form of a tree structure. An RC is the top-most certificate of the tree, the private key of which is used to “sign” other certificates. All certificates signed by the RC, with the “CA” field set to true, inherit the trustworthiness of the root certificate—a signature by a root certificate is somewhat analogous to “notarizing” an identity in the physical world. Such a certificate is called an intermediate certificate or subordinate CA certificate. Certificates further down the tree also depend on the trustworthiness of the intermediates.
Public Key Certificate
In cryptography, a Public Key Certificate, also known as a Digital Certificate or Identity Certificate, is an electronic document used to prove the ownership of a public key, as defined in PKI X.509, RFC 5280
The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate’s contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate’s subject.
In email encryption, code signing, and e-signature systems, a certificate’s subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate’s subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.
The most common format for public key certificates is defined by X.509. Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280.
Certificate authority
In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 standard.
The security of this system is underpinned by another independent third-party, the trusted Certificate Authority (CA), which issues the SSL certificate under strict guidelines and applicable regulations.
Very much mirroring the phrase ‘my word is my bond’, the support of a CA with an SSL certificate is a declaration of trust in a person, company or website. And the CA is in turn verified by a Root Certificate (RC) holder, proving that they are trusted to issue certificates and revoke them where necessary.
Should these trusted relationships fail, the SSL certificates become invalid. In that case, anyone visiting a location covered by one such certificate would immediately be warned that it has no valid SSL certificate, and that their connection may no longer be secure.
As you can imagine, the impact that a revoked certificate would have on a live business would be very serious. So it’s vital that you get your SSL certificate from the right source, backed by the most respected CA.
Having inherent trust where identity is concerned is necessary, but having the right level of certification for the business is also very important for eliminating a breach.
Theives Steal
Special relationships
When people talk about SSL certificates, it is easy to assume that they’re all the same. But depending on who authorized them and how diligent the background checks were, they come with different levels of validation.
Here are the four levels of validation most commonly used to authorize and alert/block url’s:
- Self-signed. At first glance, the idea of self-signed certificates seems mildly ridiculous, because looking in the mirror and confirming that the reflection is indeed you won’t work at passport control. However, if the purpose of these certificates is to control traffic on an internal corporate intranet, it works well enough, and avoids the browser repeatedly complaining about unsecured web locations.
- Domain Validation (DV). The next rung up is the Domain Validated SSL certificate, which is purely a confirmation that the web pages are truly coming from the expected domain and not some other. It says nothing about the person or business in question, just that they own a domain.
Domain validation is the most common, and certifies the public key and the website domain name are related. Typically, the way this is done is an automatic email is issued to the website owner that’s listed in the WHOIS database. That’s the database of people when they register a domain name. It’ll send it to whoever says that they own this website, and if they can receive that email and respond to it, then that’s proof of ownership enough. They may also ask you to post a data file on the website because if you own the website, you should be able to put a small data file up there that they can then see publicly.
- Organization Validated (OV). The highest level of validation that an individual can aspire to, and high enough for many businesses. Company credentials and those of the named owners are checked against extensive databases, including those held by local governments.
Organization Validated (OV). The same as DV in addition to advanced personal and/or business credentials and those of the named owners are checked against extensive databases: WHOIS, local, provincial/state and federal governments. The Articles of Incorporation are verified and so is the physical address.
- Extended Validation (EV). The pinnacle of SSL issuance is the fully authenticated SSL certificate, needed for any company that wants to offer their customers secure web locations, email and financial transactions.
Extended Validation (EV). The pinnacle of SSL certificates, needed for any company wanting to expand their business offer to customers in complete secure web locations especially email and financial transactions. Proves the company has domain ownership, is a genuine business, and that the certificate was applied for by authorized personnel.
As it’s reasonable to expect, checks of this type take time. Therefore, applying for and being granted an authenticated SSL certificate is not something that can happen five minutes before a new web venture is about to go live.
The other element that separates one SSL certificate from another is the level of encryption that it applies, and exactly how secure that makes it.
Encryption
The model for SSL certificates allows for the use of 128 or 256-bit encryption. Calculations show that it would take a supercomputer 13.75 billion years to test every permutation of a 128-bit encrypted code. Longer if it’s 256!
And, for good measure, the initial handshake is performed using an ultra-secure 2048-bit RSA key. Once past that awkward first date, SSL communication is usually continued with 128, 192 or 256-bit, as without quantum computers these are practically uncrackable, and they put less stress on the computers encrypting and decrypting at either end.
Most providers are offering 256-bit encryption these days, but that’s only valid when the web server, client computer operating system and browser can all operate at that encryption level simultaneously.
Old operating systems like XP and browsers can force encryption levels to 40 or 56-bit, even if the certificate they’re accessing is capable of 256-bit. It’s still only 40 bit…and hackable.
While you can’t entirely control the client end, the minimum requirement for encryption should be 256-bit at the server end, period.
Encryption with HTTPS the SSL certificates system encrypts traffic between the user’s computer and the website. Without encryption, sensitive information like passwords could be compromised by a nefarious party (a hacker) intercepting the data between the client computer and web server.
The security of this system lays in the independent third-party, Root Certificate (RC) holders who have ownership of the public key that is distributed through CA’s (Certificate Authorities) that certify the ownership of a strictly issued key (DV, OV, EV, UC and Wildcard etc.). Registration is crucial. Implementation is critical. Deployment is vital.
So, what makes a good SSL purchase?
Firstly, avoid the temptation to make choices entirely based on cost, especially if you have many sites to cover or a dynamic business environment.
Poor decisions can have big cost implications, and changing direction once you have a consumer-facing solution isn’t ideal.
The following factors should play a part in picking the right issuance operation for you:
- Period of trial – Before anything goes live you’ll want to test it, yes?
- Browser compatibility – With so many computers still running Windows XP and older releases, older browsers are a major concern.
- Issuance time frame – When deadlines are in play, time can be critical should a new certificate suddenly be needed. Plan ahead.
- Trust level type – Match the needs of the web location (your url) with the level of security and trust needed. If you don’t do financial transactions, then EV level security probably isn’t required. Not all firms offer OV level certificates and some companies try to charge for self-signed.
- Trust Site Seal – Providing a recognizable seal that the public can see is an easy way to let your customers know that a site is secure and that their information is safe.
- Support of SSL Experts – The subtle nuances of SSL and certification can be confusing even for IT people, so having an SSL support team available is critical.
- Refund Policy – Entering a business relationship assuming it will go sideways isn’t a particularly positive viewpoint, but knowing that your money will come back if needed is a sensible precaution.
- Warranty Policy – Some CAs cover errors in identification, loss of documents or intentional/accidental errors. These warranties might have implications for those companies that self-insure. You are covered up to $1 million USD by our RC.
All certificates perform the same basic function: they certify the public key belongs to a website or organization.
It is the differences in how they are issued that are important to understand:
The first difference is the domain scope. The most common type of certificate is a single domain certificate. This would be a certificate where a public key is certified to belong to a single website, for example, www.coolsite.com.
Notice that that URL includes the subdomain in front of it, www.
Our certificate and our public key would be certified only for that single domain, including the subdomain.
Wildcard – secondly, If we wanted it to apply to multiple subdomains, for example:
library.coolsite.com or members.coolsite.com
There’s a third variation on this which is the multi-domain certificate. same kind of certificate, but we’re allowed to have one public key and one certificate that’s able to be used for multiple domains.
We’d have one certificate and one public key, and we could use them for coolsite.com, library.coolsite.com, members.coolsite.com and so on.
It’d be used for coolsite.com, greatsite.org, and coolsite.net.
There’s a fourth variation on this which is the UCC or SAN certificate. That stands for Unified Communication certificate or Subject Alternative Name. Those are similar to multi-domain certificates, but they’re primarily used for Microsoft Exchange and Office communication environments.
Another difference is the level of validation for domain validation, organization validation, and extended validation. All three use the same public key and encryption.
What is different is the effort that the certificate authority makes to validate the ownership of that public key. More resources are required for verification of who that owner is.
High resources use includes a human contacting the business at a published phone number. They may speak to several people there. But just having an actual person check to make sure that someone answers the phone there and this business is who it says it is. Human vetting.
At the end of the business day, you get what you pay for. Look for a solid lock to your business front door and we can help you get the best value for your money.