Certificates are used to prove identity and used for creating secure communication. Check out http://itfreetraining.com for more of our always free training videos. This video looks at how a certificate works, what is a certificate and how they are used for identification and secure communication.
Download the PDF handout
What is a certificate?
A certificate is an electronic document that contains data fields. When compared to a traditional paper certificate there are some similarities between an electronic certificate and a physical certificate. Digital certificates like a physical certificate are issued by an authority. For example, a university may issue a certificate to a student to show that they have completed the necessary work in order to graduate. The next question is, would you trust a physically certificate? Digital certificates work the same way. They are issued from an authority and the question becomes would you trust the authority that issued the certificate? Electronic certificates also contain other fields like who or what the certificate was issued to, how long it is valid, the public key and the digital signature. If a digital certificate is presented to a user or computer, the user or computer is able to check the certificate to ensure the person using it should be using it. Also the certificate contains a digital signature which allows the certificate to be checked to make sure it has not been modified.
A digital signature provides a method for a certificate to be checked to ensure it has not been modified. In order to do this, a hash value is created for the certificate. To generate a hash value the certificate is put through a function to create a single value. Hash functions are designed so different certificates will not produce the same value, however the hash value cannot be used to generate the original certificate. The same principal applies to a person's fingerprints. They can be used to identify a person, however using a finger print you could not work out the features of a person like what color hair they have. When a certificate is created, the hash value for that certificate is also created. Using a function involving the private key, a digital signature is created and added to the certificate.
Digital Signature Example
When a certificate is used, in order to check the certificate has not been changed, the following is done: The computer generates the hash value for the certificate. Next, the digital signature is put through a function using the public key which should result in the same hash value. If both values match, the certificate has not been modified. This prevents a 3rd party taking a certificate, changing the values in the certificate and using the certificate.
Certificates work off a trust model. An example of a trust model in computers is that a computer may have a sticker on it indicating which operating systems it will run. The consumer, seeing this sticker, must trust that the manufacture would not put this sticker on the laptop unless it will run that operating system. The customer must also trust the creator of that operating system would not allow a computer manufacturer to put a sticker on a computer that would not run that operating system.
Certificate Trust Model
Certificates are generally deployed in a hierarchy. At the top is the root certificate authority. This can be an internal Certificate Authority or an external authority like VeriSign. When an authority like VeriSign issues a certificate, they will perform a number of checks on the individual purchasing the certificate to ensure that they are a valid business. When a certificate is used it can be checked to see which authority issued that certificate. In order for the certificate to be used, the computer must trust the authority that it was issued from. Authorities like VeriSign are trusted by default on most operating systems.
If a certificate is presented to the computer and it is not trusted, the computer will generate an error asking if the users want to trust the certificate. It is up to the user to decide if they believe the certificate is valid.
Certificates use a hierarchy. At the top is the root CA, below these are subordinate CA's. Any level can issue certificates to subordinate CA's or direct to users, computers or devices. If the user, computer or device trusts the root CA, then any certificate that is issued by any CA in the hierarchy will automatically be trusted and thus used by the client.
"MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition" pg 771-775
"Public key certificate" http://en.wikipedia.org/wiki/Public_key_certificate
but the root CA can't just install the certificate on the client browser automatically, how does it work?
does the client get a message like "do you trust this root CA?" ? if so then most common users will not understand what it is and click yes and then man in the middle attacks can happen
This is why prudent IT policy is required to properly distribute the certificate to the clients in the domain. For the most part, 3rd party certificate authorities act as the trustee for Internet purposes and HTTPS, however within domains ideally the root CA would create the certificate and then certificate authorities (CA) would distribute via appropriate channels. You'd want to secure the root CA since if it becomes compromised, the attacker can create fraudulent certificates and perform man in the middle attacks.
what if the certificate is captured by the hacker by downloading and uses it to bluff other victims with out changing any data in the certificate so that the integrity is maintained when checked by digital signature !
When you look at how PKI works, the certificate provides the public key to encrypt the message. Thus only the intended receipt can decrypt the message with the key. Here's a further explanation:
The use of Public Key Infrastructure as a framework for secure
transmission of data over the internet is standard practice. All SSL
(Secure Sockets Layer) certificates use this method to encrypt data at a
client and send it to a server where is decrypted through a paired set
of keys. These keys are also linked to a unique certificate that
identifies the applicant to the cert as being valid and trustworthy. The
verification process is complete by a Certificate Authority.
There is also the use of PKI certificates to provide
encryption and digital signatures for emails. This is also completed
using the Public Key Infrastructure framework and the use of the paired
public and private keys. Through this type of Public Key Cryptography,
there is a universal ability to transmit and read data only between the
desired sender and the intended recipient. This too requires a
certificate that is vouched for as validated by a Certificate Authority.
This, in turn, builds in trustworthiness for those using the
system. This trustworthiness is based on five different components of
the framework. These include the ability to send the information with
confidentiality, ensure the integrity of the information during the
transmission, verify the authenticity of the sender and receiver as well
as provide access control and non-repudiation of the sent data.
However, before the public and private keys can be used to encrypt and decrypt information through an SSL/TLS
or PKI certificate, the certificate itself has to be validated. This
can become somewhat complex depending on the specific pathway."
At time 5:09 of the video. Shouldn't the digital signature be made using the Public Key of the Certificate and not Private Key. Also, shouldn't the Private Key be used to get the original Hash Value back to check if the Certificate is not altered.
Think of a certificate as a file that contains data. It contains keys that are used for certificates and fields that contains data. On your computer, you will have a certificate that contains your private and public keys. You want to keep this safe. However, people need to have your public key. So, you create a certificate that contains your public key only. You give this certificate to everyone and keep it for yourself also. So, you put your certificate containing the public key through a hashing. Then use your private key to create a digital signature. When someone wants to verify it is you, they get this digital signature and apply the public key to it. The public key is in the certificate you gave to everyone. They then get the certificate and hash it. The value should be the same and thus your identity is verified.
When you attempt to export a certificate from your computer, you have the option to export the certificate with or without the private key. When you export it with the private key it will ask for a password to be applied. You never want to give out a certificate to the general public that contains your private key.
So does this mean that a Certificate has its own pair of Public and Private Keys and these don't function as Public Key Encryption technique to create Digital Signature. One is for encrypting the data (the Private Key) and the other is for decrypting the data (the Public Key). As in the Public key Encryption only the Private key can be used to decrypt the data. Just two separate keys for encrypting and decrypting.
Ok, let's say you use the public key is used to create the digital signature. Who has the public key? Everyone. So this does not prove anything. So you need to use something that only the person you are trying to prove the identify has. Which is the private key.
To think of it easier, think of it as two keys. We label each key public and private to make it simple. But it works like this. Use k1 to encrypt. Use k2 to decrypt. Or you can do this. Use K2 to encrypt. Use K1 to decrypt. Easy, which every key is used to encrypt, use the other to decrypt.
So, it would seem that all you would need to do is encrypt with the private key a known value. For example the persons name. If you decrypt this with the public key you would get the persons name, so this would seem to be the easier way to do digital signatures.But, we don't do it that way, why?
The problem is that if you know the data, public key and the encrypted data. You have enough information now to determine what the private key is. So, to get around this, we use a hash function. We hash some known data that both sides have, in this case the certificate as both parties have it, then we encrypt hash this with the private key making a digital signature. The digital signature can be decrypted with the public key giving us the hash. Now if we put the certificate through the hash function, if both are the same the digital signature has been validated. Since we have put a one way function in the process, we cannot no longer get the private key. It a complicate process, but it is done that way to identify the person who created the digital signature has the private key and make it so you can't go backwards and get the private key.
Lets see if understood this please. When accessing a web site, your computer downloads the cert from the site and then determines if it can be trusted based on the cert authority or who issues it. If trusted , your computer uses the public key for that domain ? to encrypt. The web server on particular domain can decrypt using the private key. That forms the secure ssl channel. Sound good or not ?
So can people who make the certificates track what you do online? Where I attend, it comes up with the following screen at 11:49 on your video. The IT tells peers to download a .cer file from their website. When I install the .cer , can it have some vulnerability or negative impact to me when I install and trust their certificate on my computer, for instance, when I am at home can it track stuff or do other harmful things???
Best of luck, though investigating ICOs are better served by looking at the whitepaper of the coin you are specifically looking into. Those that don't have a well written enough whitepaper, pass and find another.
Can someone please correct me on this understanding? SP has a local copy of the digital certificate issued by CA connected to the users IDP. When user accesses SP's website, users certificate is downloaded by the service provider, the service provider uses their public key to calculate the hash from the signature of the downloaded certificate. What is that hash compared to?
Thanks for sharing this kind of informative video source. This video is very helpful to all website owners.
Here i shared one more informative web page for #SSL Certificates - https://www.instantssl.com/ssl-certificate.html
*(Updated)* 5:09 The hash is put through (what is known to be) the Public key, actually. In this case, that kind of key is kept private. The asymmetric key pair actually works both ways: anything encrypted with any (really, any) of two keys, can be decrypted with another key in the pair. And vice versa!
Typically, one does not want 3rd party to know the secret, thus one of keys in pair is sough to be used for encryption and is given to public, labelled "Public". The other key is kept (and labelled) P/private and is sought to be used for decryption in mind, so only destination can decrypt the message. But one can use Private key also to encrypt. And encrypted result can only be then decrypted with "Public key".
Why would one want to encrypt something which anyone can decrypt? With certificates, this is apparently the situation, when signing hash. Authority wants anyone be able to decrypt, but not to encrypt.
+jeet the keys are really "asymmetrical" keys, like itfreetraining said. One can be used for encryption - only other can decrypt - and also in opposite direction.
When using a typical scheme for "private"-"public", "public" is called a key used to encrypt data and is given to all (hence public). The "private" is called other key in pair, which is used to decrypt data and kept private. These words are to simplify concept and prevent expose of private key due to confusion.
However, in case of certificate authority, it wants others to decrypt stuff - not to hide secret, but to show secret thus prove identity to anyone - hence it gives away publically what would be called a "private key"(decrypt), and keep what would be called "public key"(encrypt). Those are clearly just labels, but very important labels.
Hence my understanding why some switched to different wording - saying "open key" and "closed key" instead of "private"/"public", to eliminate confusion.
I know key pairs and ssh handshake, spent whole week finding exact infos to properly configure sshd. :) This video was very helpful to understand certificate authentication.
If you have a look at the maths behind it, there is no such thing as a private and public key. You use one key to encrypt the other key is used to decrypt. When the keys are created one key is called private and one called public to make it simple for us to use.
Have a look in the video at 5:57. Change hash to the certificate. What do you have? You have a private key that is used to create a digital signature. The digital signature can be used with the public key to get the certificate. One key encrypts, one decrypts.
This is really bad, as it breaks the security. Since you now have something known by both sides, you can reverse the process and get the private key.
So how do you get around this?
What you need is something known by both sides that does not break security.
What you do is you create a hash of the certificate. A hash function is a one way process and cannot be reversed. You cannot get the certificate from the hash value. Same way you can't tell anything about a person from their fingerprints, but it is unique to that person.
So the digital signature and hash are used to verify the certificate is authenticate.
Both sides can create a hash of the certificate giving them a shared value. But only the side with the private key can create a digital signature using the hash. If someone were to reverse the encryption, they can't get the private key. They will only be able to get the hash, which is public anyway. Only someone with the private key can create the digital signature.
This is how digital signatures work.
No, that hash is put through the private key. This purpose of the digital signature is not to provide confidentiality of the data, but non-repudiation. If you know how public key cryptography works, data that is encrypted with one key can only be decrypted by the other. So if the hash is encrypted with the private key, only the public key can be used to decrypt it. Therefore, if the hash is able to be decrypted with the server's public key, we know that the server's private key MUST have been used to encrypt it in the first place. This provides a way to prove that the message truly came from the server, as only the server has its private key, and thus nobody else should be able to encrypt a message that is able to be decrypted by that public key. It's called authentication, look up HMAC if you want to know more about this topic.
And this is why I recommend nobody should ever trust any Certificate Authority. It has a single point of failure at the Root certificate level. If government tries to use criminal activity in order to seize control, they need only go to the Root CA in order to do so.
Too much government control and too much corporate control.
I would rather take my chances against a common criminal than against government and corporate abuse of power.
Trust no C.A.
+itfreetraining That's shocking to me. But then again, I'm a network engineer specializing in Information security. Computer fornesics. Maybe I am just too close to it.
Neh, I think I will continue to ignore all certs.
Unfortunately, this new world of connectivity requires some level of trust. If you want to interact with the others with the ability to securely communicate, then it requires trusts. That's the backbone of PKI configurations. I have enough faith in (asymmetric especially) encryption that I'm not worried about these man in the middle CA attacks.
+itfreetraining Turning off the root only protects you directly from that until a cert expires then you need to contact one of the other C.A's again. They can all be compromised.
This whole mentality of TRUST everyone and everything has gotten way out of hand.
Stop this cloud nonsense. If you have your own servers and your own internet connection, you have what you need to establish your own cloud. Don't pay some third party to host your data on their servers under their control.
And that's what it's all about, CONTROL. Others trying to control you and your data. I will never use M.S. Exchange, and like the old days, I will use nor need a Cert for my domain or email. It's all a matter of people trusting it or not. If they don't then they don't have to visit it, but odds are, they will anyways.
+kellerr13 One suggestion I've seen that mitigates this issue is to have the Root CA turned off at all times unless it is necessary to create a new certificate. After the Root CA has created and authorized the new certificates and Certificate Authorities, it gets shut down and kept safe and away from anyone who would try to get access. This would definitely assist in defeating the Government's attempts to create their own certificate with your CA. Besides, there are many reasons you will NEED a Root CA especially if you are creating your own domain and using an email service like Exchange.
Very Well Explained , thanks a lot .
I have a question related to intermediate CA , when we get SSL Certificate through ICA , do we need to include ICA Certificate while installing it in the web Server ?
If we install only our SSL cert; got through ICA , will the web browser trust our SSL cert without ICA cert? , I mean Root CA is able to identify Certificates generated by ICAs under them with out separate ICA ?
and the other question is , web browsers and client applications behave in the same manner in this regards ?
+firevenge Well, the Certificate video is about Certificates, so because we're talking about Certificates it would be hard not to mention the word Certificate in our Certificate video. Thanks for your comment about Certificates.
Very Nice Explanation !! I have few questions on this topic.
As shown in the video , In case of certificate hierarchies where multiple certificates are involved
a) On Parent server -- i have installed Root Certificate from a CA1 --- so this OS would hold the Certificate CA1 with private key
ANy webbrowser accessing the Parent server (a) would get the Root certificate CA1 with "Public Key" Installed over here.
b) Child Server ---I have a self signed certificate here OR certificate from another CA lets say CA2 ----so this OS would hold the Certificate of Selfsigned or another CA2 with private key
How can i maintain the root, intermediate and personal certificate hierarchies?
Question1 : To maintain hierarchy , is it essential that i also install Root certificate CA1 (a) with a private key on to Childserver along with CA2 certificate and its private key?
Question 2 : Any web browser accessing the Parent server (a) would get the Root certificate CA1 with "Public Key" Installed on the OS hosting browser which alone would sufficient to access Child Server (b)?
How Child Serve (B) is allowing authentication to a client with Root certificate in it, is it because its having CA1 with private key installed ?
Can you please comment on it
+Sameer Rao a) The root CA would have the certificate with the private key. It needs that to create certificates. Other computers only require the root CA certificate containing the public key.
b) I am not sure why you are using a self signed certificate. If you want a hierarchy you need to install a root CA. You do not have to set up intermediate CA. The advantage of having an intermediate is that once they are set up you can take the root CA offline and only bring it back online to install additional intermediate CA's.
Q1) To have a hierarchy you need a root CA. The private key should never leave the root CA. The private key is only needed when you create certificates using the intermediate CA.
Q2) With certificates you have a chain of trust. For each CA it goes through the client will need a certificate from that CA containing it's public key, otherwise the chain of trust is broken.
+smorinator The administrator will need to install it on the client. This can be done manually or via a product like Group Policy. Remember, the standard root CA certificate does not have the private key, so it is safe to copy and distribute the certificate.
Tell me if this is right: If I wanted to start my own certificate issuing authority, I would only be able to serve computers being manufactured from now on since I have to have my root trust pre-installed on the OS? For computers already in existence and in use, it's too late, they'll never trust me since they have no internal record of me. Is that right?
+Raphi Stein Certificates work off trust, so unless the computer trusts the CA it will not be able to use the certificate. In Active Directory Certificate Services the trust that is created when the computer is joined to the domain is used to issue certificates to the computer. With a standalone CA, you need to get the certificate on the computer so it will trust the issuing CA. If you are using a commercial CA, chances are the root certificate is already pre-installed on Windows.
+Raphi Stein From what the video has told me, you need to install the root CA certificate on any computer that you want to trust the child certificates for. So, for computers already in existence and use, you would need to install the Root CA certificate. If anyone else wouldn't mind chiming in, if I am right, this would help solidify my understanding of the topic.
Cult Film Collective and the Trylon team-up for a can’t miss for film fans Pedro Almodóvar 35mm Double Feature. [TIX] First Ave is insane this week, including the annual Rebel Rebel: Rock for Pussy David Bowie covers benefit for Feline… Continue Reading →
Quick Q+A: George McConnell + SUPERHERO.
As Captain America says in the under-appreciated Age of Ultron, “We have an enhanced in the field.” Not just the field, Cap. Everywhere you look these days Superheroes are flying or speeding or stretching by—in our films, in our art,… Continue Reading →
Whiz Bang Days Celebration.
Bird Town (as we know it) aka Robbinsdale (as you maybe know it) has a proud history of wrasslin’, so we shouldn’t be so surprised to see the high flyin’ brawlers and knuckle sandwich makers and #1 heel Darin Corbin… Continue Reading →
Sat // The Beer & Bacon Classic.
Previous beer fest experiences (and there have been many) indicate the snacklace is reaching an all-time high in sophistication—but you’ll want to leave it at home for this one. Consider it research for your next creation: the Bacon and Beer… Continue Reading →
Bell Museum Grand Opening.
The Bell Museum celebrates nearly 150 years of existence, 50 years of active learning programs, and 24 feet of woolly mammoth at its grand opening this weekend, which welcomes the public to experience its beautifully grandiose new digs in St…. Continue Reading →
Lumières Françaises + Bastile Day.
Did the MSP Film Society know France would be on the cusp of a World Cup win when they planned their week of independent French film? DID THEY? The smarties actually likely scheduled Lumières Françaises to coincide with Sat’s Bastille… Continue Reading →
Weds // TV Girl + Infinity Crush + Cheap Fantasy.
“Here in New York you don’t need excuses to dress like a girl.” The effortless hipster cool of TV Girl’s sound mixes a sunny produced pop, throwback to ’60s French yé-yé, with more relaxed late night beats and samples, making them… Continue Reading →
Thurs // The Summit Ratskeller’s Grand Reopening.