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.
Related
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
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'm configuring stuff on the provisioning portal for a new app which will use APNS.
When I went to configure the App Id for pushes the web site popped up a dialog saying I had to use Keychain Access and request a certificate from a CA.
However this is a step I've already been through with a previous app, therefore is there any need to do so again? If there's no need, is it still a good idea, and if so why?
If there's no need to generate a CSR again, then I no longer have the CSR file from previously, so is there anyway to recover it?
Certificates belong to hostnames.
If the hostname is the same, yes you can.
If it is a subdomain, and the certificate is a wildcard, yes you can.
If the hostname is different, you can generate a new csr and apply for your new certificate.
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).
I am using Ruby on Rails 3 and I would like to know some information in order to buy SSL certificates.
I have a RoR application at this URL
pjtnam.com
and another RoR application at this URL
users.pjtname.com
If I make an HTTPS request from the application pjtname.com to the application users.pjtname.com like this (in this example I use the Typhoeus gem)
Typhoeus::Request.get(https://users.pjtname.com/sign_in)
and I must receive the response over HTTPS protocoll, how many SSL certificates I must buy?
UPDATE
How many SSL certificates I must buy if
my pjtname.com and users.pjtname.com applications are located on different server?
my applications are pjtname1.com and pjtname2.com and they are located on different server?
If done properly, just one; a wildcard certificate for '*.pjtname.com' and 'pjtname.com' (it's possible to include more than one name in a single certificate).
While you could instead get a certificate for 'pjtname.com' and 'users.pjtname.com', such a certificate would no longer be sufficient when you later decide you need a 'mail.pjtname.com' or a 'chat.pjtname.com' or whatever. The wildcard would cover these future cases.
re: update
It doesn't matter if services are located on different servers; just put the certificate on both servers.
It's possible to have both 'foo.com' and 'bar.com' in a single certificate, just like you can have both 'pjtname.com' and 'users.pjtname.com'. However, it might more difficult to acquire the foo/bar certificate than the pjtname.com/users.pjtname.com.
Also, these answers are true regardless of platform.