In iOS, if pinned SSL certificate expires, do I need to re-submit the app? Will the apps with old version continue to work or will not work unless they are updated?
That entirely depends on how you pinned the certificate. Pinning a certificate means checking the certificate and its chain against a set of designated requirements that determine whether the new certificate should be accepted. There are nearly an infinite number of ways to do this, and thus nearly an infinite number of ways to shoot yourself in the foot while doing so.
As a rule:
If you are checking to see if the certificate's public key matches, you're fine as long as the new cert has the same public key. This is normally the simplest approach to get right, because you have the power to guarantee that a key under your direct control does not change. However, be aware that some automated certificate updating tools generate new keys by default.
If you are comparing the entire certificate, it will likely break, because obviously some aspects of the certificate (minimally, the expiration date) will change.
If you are comparing specific aspects of the certificate, such as the public key of the CA cert that signed it, it may or may not break, depending on whether those designated requirements match.
Be aware, however, that CAs periodically rotate out their signing keys to limit damage in the event of a key getting compromised. What this means is that the specific CA cert key that you pinned may not be the one that gets used to sign a subsequent certificate. And if you are doing this in an automated fashion, it isn't a question of whether you will break, but when.
For this reason, if you feel the need to do key pinning, it is strongly recommended that you pin only keys that are under your direct control, and that you force any automated update tools to reuse the existing key pair.
No. once you install ssl on your site or renew old one, it will start working. no need to resubmit the app.
read more at SSL Pinning and certificate expiry
Related
I just deployed my side project and I'm adding the HTTPS certificates.
I was able to setup the certificate for the root domain but it looks like it's impossible to add it to my subdomain www - The UI's dashboard only let you setup one domain.
I ask that since I need two certificates - WWW and NON-WWW - to be able to redirect the WWW to NON-WWW.
You can create another certificate with a different domain, then create and activate a bundle for it as well. Nanobox doesn't limit the number of certificates you can add to any of your apps.
The process of adding a certificate is a bit involved, whether Nanobox is in the loop or not:
The first step is to create a certificate signing request (CSR), essentially a certificate with all the information about your domain (including the public encryption key), but no security. Nanobox refers to this as "creating a certificate", a process that starts every time at the "SSL/TLS Certificates" screen of your app's Admin tab.
The next step is to get that CSR signed, which is where all the security is layered in. Nanobox refers to this as "generating a bundle", since it pulls in the certificate used to sign yours, as well as any ancestor certs that may have.
The final step is to actually load that collection of certificates, also called a "chain of trust" or just "certificate chain", onto your server, where your site can use it to secure communications with itself. Nanobox calls this "activating the bundle", and it involves passing the certificate chain (the "bundle") to the app's load balancer, and telling it which domain to use that particular bundle for.
Here's where things get the most confusing the most often for most users with this question. The UI at this point mentions that "Only one bundle can be activated at a time" – it doesn't clarify that it means "one bundle at a time per certificate". Since you could, hypothetically, sign the same CSR multiple times with multiple Certification Authorities (CAs; LetsEncrypt is the most common CA for Nanobox apps), Nanobox supports loading multiple chains for a single CSR (or, to use the Nanobox naming, multiple bundles for a single certificate). But since SSL doesn't support multiple chains per request, you have to select a bundle to serve for the associated certificate, and that's all that bit means.
To add another certificate/bundle, go back to the "SSL/TLS Certificates" screen, by clicking that button on the left side of the page, then choose "New SSL/TLS Certificate" under any existing certificate(s) you've already added. The rest is the same process you already followed, above.
The workflow to add new certificates in Nanobox isn't the most friendly or obvious, though there are probably ways to improve on that, but hopefully that makes a bit more sense, now.
I'm debating and need to know the implications of not using the SCEP protocol for the mdm enrolment, more precisely the Identity certificate (the certificate credential used for authentication). I'm talking about the certificate in the Identity section on IPCU, as shown in the image below, with the red arrow.
I wont be pushing down profiles with sensitive informations (like vpn, email, etc configurations and/or passwords).
My use case will be 99%:
Block/unblock apps by rating
Lock/unlock device
Block/unlock web domains
From reading around StackOverflow (here and here) the following scenarios can happen.
If someone get access to the certificate he will be able to impersonate an enrolled device, but he will only be able to receive commands/profiles and not initiate commands/profiles. Am I right?
A man in the middle attack can get access to the certificate
The advantage of using the PKCS12 embedded within the profile is that it is faster to implement and no external dependencies (SCEP server) but I'm not so sure about the disadvantages. So my questions and doubts is:
What can a malicious person do with the private key from the Identity certificate?
Can it be a security breach going with the PKCS12 embedded approach?
This is mostly a question of SCEP vs PKCS12 embedded within the profile, pros and cons.
Here my thought on that:
1) If you are building a prototype or a small not critical service then go with PKCS12.
2) If you are building a serious product (production and touching devices of people with sensitive info) then go with SCEP (you can get a free SCEP servers. It's not that complex).
Frankly, If I was on the dark side (trying to hack it) I don't think that I would attack PKCS12 vs SCEP (it's not the weakest link)
However, let say, I say I decided to try to hack it
I would try to do man in the middle. I will try to capture communicarion, save PKCS12 and password for it
I will use it to authenticate to MDM server.
You are right, I can't trigger any commands, but I can start probing your code to find where you skipped some security checks. Maybe you don't check that a certificate matches a device UUID and so on.
Hopefully, I will find enough security holes to do something (let say trigger actions for other users). Maybe I will send them Wipe command or may be I will try to install a root CA + HTTP proxy configuration to see all their traffic.
Anyhow. I don't think that it's that weakest link and it requires a lot of additional step to get to some interesting stuff. However, if you get there, you can do A LOT.
As a result for a serious product, it will make sense to invest several additional weeks in SCEP.
I've got several hundred users on this enterprise app. I've got 2 which are throwing a NSURLErrorServerCertificateUntrusted and won't talk to the server. I've checked the server and the cert is valid, but that didn't surprise me because this issue only impacts these 2 users.
I've had them check date/time on their iPads and they are set correctly and automatically.
I've had them connect try through both cell network and a local WiFi hotspots. It seems unlikely these two users are always being targeted by a man in the middle attack.
This Question never got an answer and Apple's TN2232 document on Trust offered some common issues, but hasn't gotten me to a resolution yet since mostly these things would impact all users, not just a couple.
missing issuer certificate — For any given certificate (except the trusted anchor), the system must be able to locate the certificate of the issuer.
date problems — For any given certificate, the verify date must be within the certificate's valid date range.
self-signed certificate — For any given certificate, if the certificate is self-signed, it will cause evaluation to fail (unless it's a trusted anchor).
no trusted anchor — The system must be able to follow the path of issuer certificates leading to a trusted anchor.
DNS name mismatch — The DNS name that you're trying to connect to must match the name in the server certificate, as described in the previous section.
Any ideas on what is causing this and how to resolve it? Yes, I could just bypass the security and trust my domain, but that's not really an option I'm willing to entertain.
I'm trying to figure out what exactly means the status code errSecDuplicateItem for the SecItemAdd method when trying to add a certificate identity to the iOS keychain.
Reading the iOS documentation, it only says that this status code means the item is duplicated in the keychain, but what is the criteria to determine if an identity is a duplicate? Issuer name? Expiration date? Both?
If you read to the Mac OSX documentation, the discussion section for a similar method says the following:
If the certificate has already been added to the specified keychain,
the function returns errSecDuplicateItem and does not add another copy
to the keychain. The function looks at the certificate data, not at
the certificate object, to determine whether the certificate is a
duplicate. It considers two certificates to be duplicates if they have
the same primary key attributes.
I know there is a difference, I'm trying to save the certificate identity in the keychain, and this discussion is for the SecCertificateAddToKeychain method which saves the certificate; but I believe there is a connection.
What's the meaning of "primary keys attributes"?
I tried adding the same identity twice and of course I get the errSecDuplicateItem, but I'm afraid that users may get an error if they want to update the certificate in someway I'm not considering.
Any thoughts?
Thanks in advance
As far as I know, the keychain's primary key attributes aren't documented. However, according to a message from Ken McLeod, certificates are identified by their certificate type, issuer, and serial number. The keychain will refuse to accept more than one certificate that has the exact same values for these attributes.
Certificate authorities are required not to issue two certificates with the same serial number, so this error is unlikely to happen for your users. If you're generating certificates yourself, you must also make sure you do not accidentally reuse serials.
For one of my iOS apps I need to check two things:
Is there an active device lock (pass code)
Has the device lock been triggered by the correct authority / certificate (e.g. my own certificate). This is required to assure specific security guidelines.
For the first part of my question I found this answer - which is sufficient for me. How would you accomplish the second part?
Answering my own question.
First of all the correct question is not about validation of a certificate. It's about validation of meta information placed within a configuration profile (which in my case provides security guidelines for the device lock).
You have to create a custom CA and issue one certificate. The issued certificate has to be placed within your app, the custom CA's certificate goes into the configuration profile.
If the configuration profile is installed it is possible to check whether the certificate within the app binary was signed with the root certificate placed in the configuration profile.
It's not the most secure solution, but definitely a way to go.
--
This post put me into the right direction (Apple Developer Account required).