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.
Related
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.
I'm trying to understand what the certificate is. I'm talking about the .cer file.
In the description it sounds like it is a public key but if it is, than why do I need Certificate Signing Request (CSR) when creating it?
Everywhere I can find "what is a developer certificate for" and so on, but there is no information what the certificate — as an entity — is.
So my questions are:
What is .cer file? (Not .p12)
What is the difference between certificate and public key?
1) The .cer is an commonly used extension for certificates.
Certficates are digitaly signed and encoded documents. To my understanding certificates are documents which contain data (strings etc.) and are encoded. Simply put it is a container for sensitive data.
For details read: DER vs CRT vs CRM vs PEM
2) The public key simply put is a value (String for example). This value is stored in a certificate .cer file.
For better understanding this video might help: Private and public key
The difference is that a certificate can contain a public key but a public key cannot contain a certificate.
A certificate certify who you are, its a kind of identity card or passport or whatever. A public key is something used to secure something, somehow like a real key closes a safety box not to let everyone have look inside.
Then you may have the need to certify that a public key is the one it claims. A certificate is (normally) obtained from another trusted authority (like your passport is delivered by a legal entity). If not how would you trust a public key I'll give to you? It can be a hacked public key, but if you have a certificate that belongs to it, then (if you trust the authority) you'll know it's really mine and not a forged one.
You may read Public Key Certificate on Wikipedia for example.
.cer files are certificates in some well defined format.
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.
PKI Question
I am trying to learn about Public Key Infrastructure (PKI). I read the following example from a book for how two users can participate in a PKI. The only part I do not understand is step #10 "When Diane receives John’s certificate, her browser looks to see if it trusts the CA that digitally signed this certificate. Diane’s browser trusts this CA and, after she verifies the certificate, both John and Diane can communicate using encryption.". What is a real world example of how Diane's browser looks to see if it trusts the CA? I thought Diane would only be accessing a web server through her browser not an end user like John.
PKI Example from Book
Now that the fundamentals of PKI are understood, let’s walk through an example. Suppose John needs to obtain a digital certificate for himself so he can participate in a PKI. The following are the steps to do so:
John makes a request to the RA.
The RA requests certain identification information from John, such as a copy of his driver’s license, his phone number, his address, and other identifying information.
Once the RA receives the required information from John and verifies it, the RA sends his certificate request to the CA.
The CA creates a certificate with John’s public key and identity information embedded. (The private/public key pair is generated either by the CA or on John’s machine, which depends on the systems’ configurations. If it is created at the CA, his private key needs to be sent to him by secure means. In most cases, the user generates this pair and sends in his public key during the registration process.
Now John is registered and can participate in a PKI.
John and Diane decide they want to communicate, so they take the following steps.
John requests Diane’s public key from a public directory.
The directory, sometimes called a repository, sends Diane’s digital certificate.
John verifies the digital certificate and extracts his public key. John uses this public key to encrypt a session key that will be used to encrypt their messages. John sends the encrypted session key to Diane. John also sends his certificate, containing his public key, to Diane.
When Diane receives John’s certificate, her browser looks to see if it trusts the CA that digitally signed this certificate. Diane’s browser trusts this CA and, after she verifies the certificate, both John and Diane can communicate using encryption.
I've been handed an iOS app codebase, which I'd like to distribute via the existing Enterprise certificate used by the prior developer.
After importing the provided .mobileprovision file, I'm (not unsurprisingly) getting the "Valid signing identity not found" error. Specifically when building:
The identity '[name]' doesn't match any valid, non-expired certificate/private key pair in your keychains
I was given the original CertificateSigningRequest.certSigningRequest file, a .p12 file, and the .cer file. I was not given the password to the .p12 file.
Is it possible to rebuild what I need from the CertificateSigningRequest.certSigningRequest without the .p12 file's password? I can likely get the .p12 password, but not in a timely manner.
Thanks!
I recognize that you've solved your issue by getting the password for the .p12 file, but I thought I'd shine a little light on what lives in each of those files you mentioned for the benefit of anyone running across the question in the future.
To answer the main question in this question: Can I rebuild what I need from the CertificateSigningRequest.certSigningRequest file?
Regrettably the answer is a very solid 'No'. The root cause of this is the very heart of Public Key Infrastructure (PKI), a set of management technologies, people, and practices dealing with the creation, verification, use, and revocation of digital certificates. Central to PKI is the notion of a public-private key pair. The 'Public' key is the one you share widely, anyone may have a copy of it and anyone wishing to validate messages signed by a digital certificate will require access to this key. The 'Private' key is the linked key that only you (or more accurately, your machine) knows and uses when signing messages. It is this signature that is verified via use of the 'Public' key that is shared widely authenticating that the message is in fact authentic.
When we are constructing development or distribution certificates, we are inherently asking Keychain Access, openssl, or your preferred SSL toolchain to create a public-private key pair. The public key goes into the CertificateSigningRequest file along with the other 'Subject' fields like name and email address and we ship this file off to Apple. That file primarily tells Apple what Public Key they can use to validate your app signature -- it does not give them a copy of your Private Key after all, if others had your private key they'd be able to codesign as you effectively destroying the notion of accountability on the iOS platform (ex. This App's signature checks out as valid, but I still don't know if it was actually signed by a developer I trust...). At no point in time, is your Private Key transmitted to Apple or the Developer Portal; it resides quite happily in your Keychain until such a time as 1) The certificate expires, 2) you actively revoke the certificate from the Developer Portal, or 3) you accidentally (or intentionally) delete the keypair from Keychain.
So what lives in each of these files?
CertificateSigningRequest.certSigningRequest - This contains a copy of the Public Key from the Public-Private keypair you generated locally, plus some additional required subject information required by the Certificate Signing Request format. Apple disregards this additional information and uses the name and email address they have on file for your Developer Account when constructing your certificate.
.p12 - This is a PKCS#12 formatted file containing a copy of the Apple-issued Certificate (which itself contains the Public Key) and a copy of the linked Private Key. This data is encrypted to prevent unauthenticated access and thus requires a password to decrypt.
.cer - This is the Apple-issued Certificate that contains the Public key portion of the key pair. This certificate is used by Apple to validate that Apps you submit are not tampered with while in transit to the App Store review team:
You sign your app using the Private key that only you know and upload the signed binary to Apple.
Apple then validate the signature using the public key that you've already shared with them.
If the math works out, then the App hasn't been tampered with and you are good to go.
If the math doesn't work out, either the app was tampered with, or (much more likely) the certificate was revoked or regenerated and the app was signed with an old or incorrect key pair.
As you can see, the only places the Private Key resides is in the original developer's keychain as well as the encrypted .p12 file. Consistent with both your comment and flup's comment, you either have to get the password to that .p12 file or look into breaking through the encryption.
Regardless, good to hear that you were able to get the password from the original developer. Let me know if you have any followup questions.