I'm trying to figure out how trust anchors play a part in the PKI. I understand that it's the root of the certificate chain and is used to validate if a certificate is trusted or not. How does it validate a certificate? (eg. how does it use a public key and the certificate chain to validate a certificate?)
A certificate binds an identity to a public key.
Suppose you get a digitally signed email from me. If you validate the signature with a public key in your possession, then as long as you trust that people are keeping private keys private, you know that email came from someone who had the private key corresponding to that public key.
If you know for sure that the public key you have is mine (e.g. because I handed it to you personally) then that's all you need to know. The problem is you don't always know that. Anyone can create a key pair and sending the public key all over the internet falsely claiming to be me, or set up a web server falsely claiming to be StackOverflow, or whatever else. You could find out Google's phone number from an independent source and call them up to confirm you've got the right key, but if you had to do this every time you wanted to make a secure TLS connection then e-commerce would be considerably more inefficient than it is now.
One solution is to get hold of a certificate. This contains a public key and identity information (e.g. name and address, domain name, email address) that is digitally signed by a certificate authority. If you validate the signature in the certificate with the certificate authority's public key, then you know that someone who has access to the certificate authority's private key was happy to sign a certificate stating that they agree that that identity goes along with that public key. If you trust that the certificate authority is not to do that unless it's taken reasonable steps to verify that that's true (e.g. by making sure they see the individual's personal identity documents, and verifying that that individual has the private key corresponding to the public key that's going to appear in the certificate) then you can trust that you have the right key for the right individual.
But even if you have that trust, this just pushes the problem one step up the chain, because to validate the certificate in the signature with the certificate authority's public key, you first need to be sure that you have the right public key for that certificate authority. So you might get a certificate for that certificate authority, and find that it's been issued by a different certificate authority, and so on.
You obviously can't validate an infinite chain of certificates, so at some point this all has to stop. Eventually you have to verify that you have the right public key for the top-level certificate authority without relying on another certificate to do so, and this is your trust anchor.
So suppose you have a certificate for me, and you see that it's signed by ABC Certificate Authority, a certificate authority that you've never heard of. You get the certificate for ABC and use the public key in it to verify the signature on my certificate, and this proves to you that ABC Certificate Authority really did issue my certificate.
Then you look at ABC Certificate Authority's certificate, and you see that it's signed by DEF Certificate Authority, a certificate authority that you do trust and for which you already have a self-signed certificate, or trust anchor. You use the public key in DEF's certificate to validate the signature in ABC's certificate, and this proves to you that DEF really did issue that certificate for ABC.
To be sure that my certificate is valid, you therefore need to do a few things and make a few assumptions:
You need to get and trust a (self-signed) certificate for DEF Certificate Authority, which is your trust anchor. In most cases your browser and/or operating system will come pre-loaded with a bunch of CA certificates that the manufacturer has decided to trust, and you'll just blindly trust the manufacturer's judgment on that, but you can take your own steps to validate that trust yourself if you want to.
You need to have confidence that DEF is a legitimate and trustworthy certificate authority that's going to keep its private key secure and isn't going to issue certificates to anybody unless it has good reason to do so. Again, you'll most likely trust the manufacturer on this one, but most CAs undergo regular audits of their certificate issuance processes and controls, so if you're concerned you could get hold of the last audit report for that particular CA, for example. Note that doing this requires that you trust the auditor's judgment, so whichever way you go, at some point you have to trust somebody just because they're trustworthy.
You need to have confidence that DEF wouldn't issue an intermediate CA certificate to ABC Certificate Authority unless it had good reason to believe that ABC was also a legitimate and trustworthy certificate authority that's going to keep its private key secure and not issue certificates without a good reason. Here you don't trust ABC directly - you trust it because DEF trusts it, and you trust DEF.
This same logic applies if there are more than one intermediate CA certificates in the chain between the trust anchor and the end-user certificate - you're effectively trusting every intermediate CA in the chain on the grounds that the preceding CA in the chain wouldn't have issued them their CA certificate unless it was satisfied they were a trustworthy CA and unless it had validated that the public key in the intermediate CA certificate really did belong to that intermediate CA. By validating the signature in each intermediate CA certificate with the public key of the CA immediately before it in the chain, you demonstrate that the preceding CA really did issue that certificate. Since you explicitly trust the root CA, then if your trust anchor is found to be at the bottom of that chain then you've built an implicit chain of trust that gives you confidence that the end-user certificate you were originally interested in is good.
Ultimately it's all based on the idea that you just explicitly trust a handful of well-known root CAs, and then you can implicitly trust any of the billions of other identities on the internet if you can find a chain of valid certificates going back to one of those roots that you explicitly trust and if you're willing to accept the notion that every intermediate CA in that chain is trustworthy on that basis.
The reality is that certificate authorities are usually very careful about issuing intermediate CA certificates, and when issuing them to third party organizations often restrict them, so that an intermediate CA certificate issued to ACME Inc may only be used to issue certificates for ACME Inc employees, or to issue certificates only for domains that end with .acme.com, for example.
Trust relationship, trust chain, and trust anchor
A trust anchor has to do with how a trust is established during a secure transaction, as when going to a secure website, for example. When a website presents a certificate to you, how do you know you can trust this certificate? Well, because it's signed by another certificate which belongs to an entity you trust as a Certificate Authority (CA). (More on signatures and verification below.) But how can you trust the CA certificate? Because it was signed by yet another certificate belonging an entity you trust. You can repeat the steps of asking the same question about this entity and getting the same answer about yet another signer, until you get to a certificate which was not signed by another certificate. In fact, it's a self-signed certificate. This is called the root certificate. So, how do you know to trust THIS certificate? The answer is you just do, usually because it's bundled with your browser or other software when you install it or you just accept that you trust this cert. This set of related certificates with the CA certificate, signed by another certificate, signed by another certificate . . . signed by the root certificate, is called your trust chain and the root certificate is the trust anchor because it's trust is not derived from another certificate; it's just accepted as being trusted, whereas all the other certificates directly or indirectly derive their trust from the trust anchor.
What is a digital signature and how is it verified?
Asymmetric Keys --
There are a pair of digital encryption keys associated with digital certificates. This pair consists of a public and a private key which have a special relationship to each other. Something encrypted by a public key can only be decrypted by the private key and vice versa. "Asymmetric" refers to the fact that if one is used for encryption, the other must be used for decryption as opposed to a single key being used for both encryption and decryption. The private key, as the name implies, is kept private by the entity to which the certificate is issued, but the public key is available to anybody and in fact, it's included with the publicly available certificate. An Asymmetric key pair makes digital signatures possible as well as PKI in general.
Hash (Digest) --
Another concept in understanding a digital signature is a hash or a digest. A hash function takes data of an arbitrary size as its input and produces a fixed size representation of this data as its output. This output is known as a hash or a digest of the data. A sophisticated hash algorithm, such as MD5, produces a hash value which has the following properties:
Given the same data and same hash function, the product is always the
same hash value every time.
Two different sets of data will almost never produce the same hash. In fact, even if there is a small change to the data, the two hash values will be completely different from each other.
Not pertinent to this discussion, but as a general note, the original data cannot be derived from the hash. For this reason, a hash is sometimes also known as a one-way encryption.
Creating and verifying signatures --
A signature can be created by taking a hash of a document such as a certificate and then encrypting the hash using the signer's private key. So, a signature is just an encrypted hash. A Certificate Authority (CA) creates a digital signature for a PKI certificate using the CA certificate's private key. The signature is always included with the PKI certificate.
To verify a signature the verifying entity, such as the browser, would:
Un-encrypt the signature on the PKI cert using the signer's public key which gives you the hash of the PKI cert
Create another hash of the certificate
Compare the un-encrypted signature and the hash you just created for the same certificate. If they are the same, the signature has been verified.
So, because you can un-encrypt the signature using the signer's public key, you know that it could only have been encrypted with the signer's private key, and therefore unless the private key has been compromised, the only entity who could've signed the certificate is the CA to which the signing cert belongs.
And because you created your own hash of the same data with the same hash algorithm and it matches the un-encrypted signature, you know that the signature was created from the cert you're trying to verify and that it hasn't been tampered with.
In summary, you've established this is a valid cert because it's signed by an entity you trust because that entity's certificate is signed by an entity you trust and so on, until you reach the trust anchor (the root) which you trust by acceptance.
Hope this answers both your questions.
Related
I am looking at a clear answer on to how to renew the CA successfully in EJBCA. We have thousands of client certificates already issued by the EJBCA which is actually working as a subCA signed by an external CA. The process is indeed documented here https://www.ejbca.org/docs/Renewing_a_SubCA_Signed_by_an_External_CA.html but it does not state clearly, what will happen to the already issued client certificates. Will they continue to be successfully validated via the new CA?
That link give two options for renewing the key:
1. Using the same CA signing key
If you refer to RFC 3647, this is the correct definition of a renewal. In this case, the keys remain the same and the certificate Subject remains the same. Effectively, the new certificate is the same as the old albeit with different dates.
Relying parties will trust this certificate in the same way as they trusted the original.
2. Generating new CA signing keys
The correct term for this is a re-key. The key changes and the Subject stays the same. The certificate is a different certificate as far as any relying parties are concerned. This may mean more work for you.
You'll first need to ascertain what will happen to the original CA certificate. Will it expire or be revoked, or will it still be valid?
If it's being retired, you'll need to replace all certificates issued by that original CA certificate as they will only verify through the original CA.
If not, and you're re-keying for other reasons, for example the original CA certificate's CRL has become too large to manage, then there is no need to rush into replacing all your subscriber certificates. The old CA certificate will still verify those certificates, while subscriber certificates issued by the new CA certificate will be verified by the new CA certificate.
Can someone explain the difference between validating a certificate like described with a self-signed certificate here:
https://jetforme.org/2013/05/validating-a-self-signed-ssl-certificate-in-ios-and-os-x-against-a-changing-host-name/
and SSL pinning like described here:
https://infinum.co/the-capsized-eight/how-to-make-your-ios-apps-more-secure-with-ssl-pinning
What does SecPolicyCreateSSL means?
What in detail is SecTrustEvaluate doing?
Is the procedure in the first link including SSL pinning?
If not, is it a good idea to implement both?
Thanks
First let's clarify the terminology in the Cocoa world:
A SecPolicyRef is a policy that defines the rules when validating a certificate chain: the things to check for in the certificates within the chain (signature, expiration date, etc.), which determine whether the certificate chain is valid/trusted or not.
A SecTrustRef object is the combination of a certificate chain (basically an array of SecCertificateRef) and a SecPolicyRef. This object represents all the things needed to validate a certificate chain (the certificates + the policy).
Validating a server's certificate chain involves two steps:
The certificate path needs to be validated (the signatures, the expiration date, etc.) to ensure that the server certificate was issued by a trusted CA.
The name for which the server certificate was issued (Common Name or Subject Alternative Name) needs to match the name of the server the App is trying to connect to.
These steps are expressed by a SecPolicyRef:
SecPolicyCreateBasicX509() returns a policy that has all the things to check for 1; this is there for historical reasons but it should never be used.
SecPolicyCreateSSL() returns a policy that has all the rules for both 1 and 2; this is the one you must use.
You then use SecTrustEvaluate() to validate the server's SecTrustRef. The result will tell you if the server's certificate chain is trusted based on the SecPolicyRef that was passed.
Lastly, SSL pinning means adding a third step to this whole process:
The certificate chain must contain a specific key or certificate. This ensures that only the certificate you know you deployed on your servers will be accepted by the App, instead of any certificate issued by any CA for your domain.
I would advise against writing your own implementation of SSL validation (with or without pinning) as, you can tell, the APIs are extremely complex and there is a big potential for huge mistakes that would make your extremely App insecure.
I have worked on a library to make it easy to do SSL pinning; it's available at https://github.com/datatheorem/TrustKit and takes care of all the heavy lifting.
I have a pretty basic understanding of PKI/SSL/TLS but not a lot of experience with it. I have several iOS devices connecting through a VPN to an internal server. The server is reachable, but we receive an SSL error. I understand I need to add the CA's cert to the iOS devices - but I'm confused as to if I add the CA's public or private cert?
According to this blog It's private, but I want to verify first.
http://nat.guyton.net/2012/01/20/adding-trusted-root-certificate-authorities-to-ios-ipad-iphone/
Any advice or further documentation would be greatly appreciated.
There's no such thing as a private certificate.
In an asymmetric encryption you have two keys - the public key and the private key. As the names suggest, the private key is kept private and the public key is distributed. A certificate is a separate object that serves to tie a public key to a "security principal" - i.e. a person, server, certification authority or whatever.
So your VPN server has a certificate. This certificate states that the given public key X belongs to your server. When you contact the server, it gives you its certificate and public key, then can prove it has the corresponding private key by you giving it a randomly generated number to sign/decrypt.
However, how do you know the server isn't lying when it gives you the certficate? Because the certificate is signed by a third party - a certificate authority. The CA's signed the server's certificate with its private key to confirm that what it says is true. You can verify this signature with the CA's public key. But how do you know that the CA's public key actually belongs to the CA?
As you can see, this can go on for a while, creating a chain of certificates or chain of trust. Eventually you have to have some certificates that you just trust without any third parties - the root certificates. iOS comes with a set of these that Apple trusts, but does not include the root of the chain for your VPN server. That is the certificate that you are being asked to install.
I am developing mdm server and I have a problem with one of enrollment steps. The problem is scep step. I implement a scep server which handles Device CACert request and sends our server certificate in der format. After that, device sends encrypted and signed csr. But I can not verify signature of message. I think device creates a self-signed-certificate and sign message with it. We think that because signature certificate's common name is changing each "PKIOperation" request. But we must verify this signature because of security.
For example in each 3 enrollment request, certificate of csr signature changes. Their common names are:
CN=6E4F65AD-1E64-4E4D-A96E-2039EB140041
CN=2E33C2CC-14B8-47AC-938B-DCC7F8DA8715
CN=6817ED48-AB79-4FF0-A1A9-42C2AC303672
Note: The other steps of enrollment device sign messages with proper certificate and I can verify them. Only scep PKIOperation request is my problem. Is there any profile flag to set or something to solve this problem?
I may be wrong in some details, because I touched this about two years ago.
However, as I remember it's part of a protocol
If you take a look at SCEP draft: https://datatracker.ietf.org/doc/html/draft-nourse-scep-23#page-30 you will see this:
When building a pkiMessage, clients MUST have a certificate to sign
the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires
it). Clients MUST either use an existing certificate, or create a
self-signed certificate (see Section 2.3).
If the requester does not have an appropriate existing
certificate, then a locally generated self-signed certificate
MUST be used instead. The self-signed certificate MUST use the
same subject name as in the PKCS#10 request.
However, I was under impression that iOS device uses certificate/private keys which are built into the device. And this certificate is signed using Apple certs. And actually, as I remember they had exactly the format of CN, which you shown.
So, generally speaking it's ok if device uses self-signed certificate for first communication to the SCEP server (PKIOperation) and uses a certificate issued by your CA later on.
Is certificate Subject the content of certificate?
such as:
Subject DN = Subject Distinguished Name = the unique identifier for what this thing is. Includes information about the thing being certified, including common name, organization, organization unit, country codes, etc.
Subject Key = part (or all) of the certificate's private/public key pair. If it's coming from the certificate, it's the public key. If it's coming from a key store in a secure location, it's probably the private key. Either part of the key is the cryptographic data used by the thing that received the certificate.
Subject certificate - the end point for the transaction - this is the thing requesting some secure capability - like integrity checking, authentication, privacy, etc.
And what content of Subject is used for IKE V2?
A certificate binds an identity to a public key. The binding is performed by the issuing authority (VeriSign, Cybertrust, etc.) digitally signing the contents of the certificate.
The Subject of a certificate indicates the entity for which the certificate was generated. If it's an SSL certificate, it may correspond to a server and include the server's DNS name, for example. If it's an e-mail digital signature certificate it may correspond to a person's e-mail address. You are correct that it includes the organizational unit, etc.
The Subject Key is the public key in the equation. While there is a private key corresponding to the certificate, the certificate itself only contains the public key.