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.
Related
I am working on implementing universal links in an iOS app. As per the requirement to implement this I have to serve an apple-app-site-association file from our server end to ensure this is our website.
My concern is that we will serve this file from our real server of course but is there any quicker way to mock this process locally or remotely so that I can bypass the testing phase at the time of implementation? As you know interrupting the other team for some small changes or trial and error seems boring.
It is recommended to have a staging server before you move/deploy you changes in the production. In cases of small projects this could be you local machine. In order for universal links to work you need two things:
The server that hosts the apple-app-site-association needs to have a valid ssl certificate. It will refuse to get the file from a http:// connection or from a https:// with an invalid (e.g. self signed) certificate, unless it is trusted by the device. To make a self signed certificate trusted check here.
The server that hosts the apple-app-site-association needs to publicly accessible because the file is delivered thru CDN, if not when you need to modify the entitlement file to add ?mode=developer, like this: applinks:ourDevServerURL?mode=developer
Currently, I am creating a localhost server using any language(in my opinion golang) then forwarding the localhost to the internet so that ios can access it from anywhere.
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 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.
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.
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.