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.
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 trying to configure a MDM for all my mobile phones. But for iPhone, I need to create a Apple Push certification to do that, but can't able to reach the portal identity.apple.com/pushcert and getting Forbidden error. Do anyone guide me what went wrong with this?
Looks like probably your trying to access using http instead of https.
https://identity.apple.com/pushcert/ should work. Else please re-check if its not the routing issue between your service provider & Apple.
Regards,
_Ayush
if you have previous files related to certificates on your computer delete them these include csr and pem files. go back to portal link and you will find it will now navigate to the actual link.
As many already know, Google App Engine by default hosts its apps on an appspot.com subdomain and their wildcard (*.appspot.com) SSL certificate allows any apps to use https over this subdomain.
Enter iOS 9 with Universal Links and Web Markup which now requires hosting a 'signed json file' with designated applinks in it. The key word there is 'signed'. This file needs to be signed with a valid SSL cert and private key. (Listing 2-7 and 2-8)
On twitter, I've been told that the signing certificate does NOT have to match the actual website's domain SSL certificate BUT a self-signed certificate will not work.
So one workaround is to simply buy your own SSL certificate and sign it with this cert.
I'm curious what other options there are to those of us hosting APIs and websites on Google App Engine and/or using Google Cloud Endpoints because I assume Google isn't going to hand over their wildcard ssl cert and private key for us to use ;)
Update 8/5/2015
To host the apple-app-site-association file, I had to manually open it and spit it out when called for using the webapp2 handler like so:
class GetAppleAppSiteAssoc(webapp2.RequestHandler):
def get(self):
showAppleAppSiteAssoc(self)
def showAppleAppSiteAssoc(self):
logging.info("Enter showAppleAppSiteAssoc()")
path = os.path.join(os.path.dirname(__file__), 'apple-app-site-association')
fileContents = open(path).read()
self.response.headers['Content-Type'] = 'application/pkcs7-mime'
self.response.out.write(fileContents)
return
app = webapp2.WSGIApplication([('/', MainHandler),
('/apple-app-site-association', GetAppleAppSiteAssoc)],
debug=True)
Currently having issues similar to this post and have tried both signing with my iOS Distribution cert as well as with a valid cert from work.
Update 8/10/2015
Had our dev-ops guy at work sign this with both the CA and intermediate certs from work and uploaded it and it worked!
Still curious about other solutions though.....it does seem odd that the iOS Distribution cert wouldn't have worked.
You don't have to sign apple-app-site-association unless your implementing Activity Continuation for devices running iOS 8. Universal Links are new to iOS 9 and Apple no longer requires apple-app-site-association to be signed.
Well one answer to this question points to the fact that any valid domain certificate (with CA cert) can sign the file (even if that certificate is NOT for the domain the file will live on).
I ended up buying one for one of my domains and signing the file for another domain.
https://developer.apple.com/library/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
If your app runs in iOS 9 or later and you use HTTPS to serve the apple-app-site-association file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it.
I'm working on an iOS app with a rails backend, running on a VPS (via my own domain).
My question is: is it insecure to use a self-signed SSL certificate on my server and ignore the warnings from NSURLConnection while communicating with it, considering that this is a private API which is only accessible via my iOS app?
The safe way to go in this scenario is: Sign it yourself and manually add the certificate to the local certificate database of every system you work from, so you don't need authentication to know it's yours. Sometimes this can be done automatically as easily as checking the box "ignore the warning for this certificate" the first time you connect from each system, which will prevent you from seen it again on that system unless the certificate changes.
This way you won't see the warning again, unless it's somebody else's self certificate you're looking at.
Ignoring the warning by default usually means that if somebody else signs its own certificate and presents it to you, you will go along without even noticing. Not a good idea.
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).