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.
Related
I can't find good information regarding certificate pinning in iOS and Amazon Certificate Manager.
They recommend you don't pin against an ACM certificate.
https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html#best-practices-pinning
We recommend that your application not pin an ACM Certificate
The reason they don't recommend it is that:
To renew a certificate, ACM generates a new public-private key pair.
Instead, they recommend:
If you're using a public certificate, pin your application to all available Amazon root certificates.
I understand why not to pin to an ACM Certificate - because you will have to release updates with new certificates risking possible bricking of clients. You also can't pin against the public key because it will change.
What I don't understand is how pinning against only the root certificates is ok? Will it still prevent man in the middle attacks? How is this more secure?
Can someone explain it better?
It would not be more secured to pin against the root certificate. I think what the Amazon documentation trying to recommend is a way that would not break your network connection in the case that when the certificate expires and renews.
Here's the quote from this website explaining the different kinds of certificate pinning:
https://carvesystems.com/news/cert_pin/
Leaf Cert: A leaf cert is the top level cert in a certificate chain.
Pinning a leaf certs brings us to almost complete certainty that the
certificate matches. However, if you cycle your leaf certs often,
updates need to roll out fairly frequently to make sure your
customer’s app continues to work.
Intermediate Cert: The intermediate cert lives between the leaf and
root cert. In this case, pinning against the intermediate cert, you’re
putting your trust in the intermediate certificate authority.
Therefore, you can update your server’s leaf cert more often, as the
validation of certs occurs on the intermediate cert.
Root Cert: Finally, the root cert comes from the trusted certificate
authority. Pinning the root cert alone puts trust in the root cert
authority, as well as all intermediaries that the root cert authority
trusts.
Hope this helps
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.
You hear a lot about how you can use SSL pinning to increase the security in your app. I was always under the assumption that SSL pinning is only helpful if you use a self-signed cert. Are there benefits of SSL pinning when using a cert signed by a cert authority, or does the CA make that unnecessary?
SSL/TLS has some issues, and the root of those issues is the CA system. By default, your browser trusts a bunch of CAs. Other than a few basic checks such as hostname, etc, the real power of the SSL comes from the verification of the certificate via the intermediaries until you get to a certificate that you trust.
Certificate pinning specifies that you will only trust a given certificate for a given web site. That is to say, if you received a "valid" certificate signed by a different CA (even if you trusted that CA) you would not trust it for this site.
In short, the fact that the CA has signed a cert does not reduce the need for certificate pinning.
For example: Companies sometimes intercept SSL. To do this, they actually serve the client a different SSL certificate that is valid for the host that the client is trying to access. Because they can insert any certificate into the trusted root (windows via GPO) they can insert their certificate instead of the actual one issued by the host. In this scenario, the SSL interception is transparent to the user. They are still being issued a "valid" certificate that is signed by a CA they trust (whether they know it or not). If you had been using certificate pinning, the new cert would be rejected.
There are cons to certificate pinning, mostly around the management of the cert as it expires etc.
See this link for more info.
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.
Okay, so look at this diagram.
There are two little boxes, that signify how a given profile should be signed.
In Phase 2, step 1, it says "Apple issued certificate", but it doesn't say which apple issued certificate (they issue more than one). I have tried my developer certificate and the MDM (APNS) certificate. It wasn't one of those. Is there a third magic certificate I somehow need (and how do I get it)?
In Phase 3, step 2, it says "Identity certificate", but again it's a little sketchy on the details. The only identity certificate I know of is installed on the device, using the device's private key, how is the server supposed to use that to sign a profile?
The only way I've gotten this to work, is by creating my own self-signed certificate, and pre-installing it on the device. Obviously this is not an elegant or particularly secure way to do things.
Follow up questions
My server certificate is issued by "DigiCert High Assurance EV Root CA" and is on the list: http://support.apple.com/kb/ht5012, but iOS 6 devices consider it "untrusted" when signing profiles, but just fine for SSL which is wierd. iOS 5 devices are fine though. Any idea why?
I don't really understand the encryption bit either. From the MDM documentation: "Each device must have a unique client identity certificate. You may deliver these certificates as PKCS#12 containers, or via SCEP. Using SCEP is recommended because the protocol ensures that the private key for the identity exists only on the device."
While I agree it is ultimately more secure that only the device itself knows its private key, it's somewhat problematic as a 2048-bit public key can only be used to encrypt about 100 bytes of data, which isn't enough for even the smallest possible payload.
Let me go over phase 2 and phase 3 first
In the Phase 2, step 1, iOS device will send to a server response which is signed by device certificate/key (each device comes with preinstalled certificate/key which is different for each device). These on device certificates/keys are issued by Apple.
On the server side, you should verify it using Apple Root Cetificate.
In the Phase 2, step 1-3 your profile service will send a SCEP request. This SCEP request contains information to let device know to which SCEP server it should talk. This SCEP server is your server. So, a device will talk to this SCEP server and will request new identity certificate from it.
In Phase 3, step 2 device response will be signed with certificate/key of this identity certificate. And now you should verify it with your Certificate authority root certificate. (One more note SCEP server in Phase 2 is kind-of proxy to yours Certificate authority)
And now answering your questions "MDM profile signining, which certificate to use?"
MDM profile could be encrypted and/or signed.
If you want to encrypt it, you encrypt it using identity certificate associated with this device. So, device which has a key for this identity, so it can decrypt it.
If you want to sign it, you sign with your server key. Device should have a server certificate installed, so it can verify signature.
BTW. On this subject. One thing which isn't shown on this diagram, but usually is requited - first step (before whole this enrollment) is usually installation of server certificate (for future profile signature verification). Potentially, you can skip this step if your server certificate is issued by well known CA (as example Verisign or something like that).
Let me know, if you have any followup questions. It took me a while to understand whole this OTA/MDM enrollment.
Update 1
I don't know why iOS 6 treat your certificate as untrusted for signing. I didn't work with certificates which were signed by well known CA's.
I have only one guess. It could be that between iOS 5 and iOS 6 they changed something regarding key chain. Generally speaking, each app has it's own key chain. And all well known certificates, I believe should be stored in Mobile Safari keychain. It could be that MDM/Preferences shared this keychain with MobileSafari in iOS 6 and now they don't share it.
In such case, you will have to install this "DigiCert High Assurance EV Root CA" through a profile (to put it in correct keychain). However, it's wild guess.
Regarding encryption. First of all, you are right, if each device has it's own private key, it's way more secure. In such case, if anybody will steal a profile they won't be able to decrypt it (because only a device has a private key to do so). This is especially critically, if you are sending down profiles which are sensitive (as example, email account with both user name and password).
Very high level introduction into cryptography:
Any key (with any length) can encrypt data of any length. All encryption algorithms are designed that way that you can use the same key to encrypt any amount of data.
Asymmetric algorithms (like RSA) rarely used to encrypt data directly. In most cases, this algorithm is used to encrypt a key for symmetric algorithm (as example AES) and all following encryption/decryption is done using AES. There are two reasons for that: performance (AES is faster then RSA) and resources (AES is less resource hungry than RSA).
So, as result, if you need to encrypt profile you use PKCS7, which is internally uses RSA, AES (or other algorithms). Usually, you have a library to do this (OpenSSL or BouncyCastle). So, you don't have to figure out all these complexities.
BTW. If you have questions which aren't good fit for SO, you are welcome to contact me directly (my contact info in my profile).