My iOS app is in development right now and the services we connect to are using a cert that is signed by our internal (company) CA. My app in many places calls secure web services using synchronous requests. It would be a large effort to switch to async and handle the cert challenge to manually accept certs from our domain.
What I would like to do is to add our CA root cert to our team's provisioning profile so that it is recognized, just in development, as a trusted CA. Can someone help me do this please?
If this is not possible, does anyone have any suggestions? Here are the options I see from best to worst.
Add internal CA root cert to trusted CAs in dev provisioning profile
Buy a cert (don't want to do this because our deployment server already has a valid cert, and i wont want to waste money on a cert that I just need in our dev/test environments).
Switch to ASI framework to bypass challenges (don't want to do this because it makes my app less secure. My code is correct and secure as is, but I cannot test in dev/test. I don't want to make my app worse just so that I can test in my dev env.)
Switch to async requests and handle challenges by accepting all certs from my domain (also don't want to make code changes for working code. Also it is a huge effort for us to switch to async, and we don't have the time).
All help is appreciated! Thanks.
Well I decided to go with 2 and just turn SSL off for our internal machines. Not the ideal solution, but I couldn't find a better one.
Related
I just started working for a new company. They are an engineering company focused mostly on hardware. They don't have a lot of experience with big data dev/test environments. The company has extensive IT security policies. One of them is "absolutely no wildcard certificates". I have worked in other software shops where wildcard certificates were commonly used in dev and test environments. The advantage is that you can spin up servers and use the wildcard certificate without waiting for the accounting department to issue a purchase order to the CA. I believe I understand all of the security issues for wildcards,
If one subdomain is compromised, all subdomains are compromised.
If you revoke the certificate, all subdomains are revoked.
Wildcards may not be compatible on "really old" browsers and servers.
Single private key floating around on several servers pose security risks.
Some CA's void their warranties for Wildcard certificates.
I probably would not use wildcards for production servers -- mostly because of #4. However, I cannot see the above security issues a problem for a dev and test environment. The dev and test servers have internet facing ports. They all have the usual password and multifactor security built-in. Only necessary ports are exposed and all are https. The data is all test and all of the servers are in their own domain with no connection to the companies internal domains.
Does anyone see any potential security problems or other things I might be missing?
I started out thinking that wildcard X.509 certificates was the way to go with moderate to large server/instance development environments. However, the suggestions of AlexP were quite helpful and I believe it is a better way of approaching the distribution and management of multiple environments and X.509 certificates. Here is a description of his suggestions.
You have several environments that you will have to support. Each environment has several servers or instances. Each server/instance requires their own
X.509 certificates.
DEV1, DEV2, ... Development environment
TEST1, TEST2,... Test environment
STG1, STG2,... Production staging and test
PROD1, PROD2,... Production Live environment
The recommended way would be to build a private SSL Certificate Authority (CA). The private CA would issue X.509 certificates for DEV, TEST, and STG. Any development or test machine browser would be manually loaded with the root certificate of your private CA. This way the browser will not squawk about certificate security problems. Each server or instance would have it own unique certificate. Each environment could conceivably have several servers or instances so you could easily have many 10's of certificates to deploy and manage. The use of sub-domain or Fully Qualified Domain Name(fqdn) is also helpful -- DEV1.admin.mydomain.com, DEV1.rest.mydomain.com, TEST1.admin.mydomain.com,...etc. You will need to use the fqdn for the common name of each certificate -- STG1.mongodb.mydomain.com for example. For the production environment, you would use a commercial CA such as Comodo, Symantec, or others. The fqdn for this environment would be mydomain.com, rest.mydomain.com, etc. Private CA certificates are free, easy to create and fast to deploy. Commercial certificates can be expensive and take more time to create and deploy but are necessary. Private CA's represents a good cost, security, and ease of certificate management trade-off in a moderate to large development environment.
I've been tasked to add security by means of certificates to an external web service we call from our ASP.NET 4.0 Webforms application.
I've been able to play around with the certificate and get the code to work properly, but there are still a lot of questions unanswered when it comes to deployment of that solution. I'm pretty new to actually using (and dealing with) certificates - I understand the basic theory behind them, just never used them much myself.
The service is an external REST webservice provided by a company which also issues the certificates - and those will expire on a yearly basis and need to be renewed yearly. So "baking" them into the ASP.NET app as an internal resource doesn't seem like a good idea.
I'm leaning towards putting them into the certificate store on the Windows 2008 Server. That works fine, but what I'm not sure about: how do I FIND the appropriate certificate from code? I know about the X509Certificate2 and X509Store classes - but what criteria should I search for?
What item (Serial number? Thumbprint?) would remain the same if that cert has to be renewed every year? Or do I have to update my config and store a new serial number or thumbprint every time the cert has been renewed?
If I understand correctly you need to ensure that you are communicating with correct web service.
You are using https to connect to the REST service. Is it a WCF service or Web API? Either way the web server will handle the SSL part (hmm, only if hosted on a web server and not self hosted). So if we make it easy then the web service is hosted on a web server. The web server will handle establishing SSL connection and will send you server certificate.
Then you need to check if you are communicating with correct web server. Your options are:
manually update config file with thumbprint that will change every time the certificate of web server will be renewed. Also serial number will change when they renew the certificate.
check for common name in the subject or better if the is correct DNS name (of the web server) in Subject alternative name (SAN = extension in the certificate) or in CN (when SAN is not in the certificate)
build a certificate chain (using X509Chain.Build method) from web server's certificate and check if it contains a CA certificate that you have embedded in ASP.NET application or if it matches given thumbprint of CA from you config.
1) - will work but you have to ensure to update config file every year
2) - will work nice until they change DNS name of the web server, but it would result in change of your web.config so ... it will work. One thing to note is that extracting any extension from X509Certificate2 class using standard .NET framework is not easy. You would need to either go to ASN.1 level or use some crypto library that can extract the SAN in a friendly way.
3) - will work nicely. You can use Root CA certificate or dedicated intermediate CA certificate. You have to ensure that web server certificate is trusted for certificate chain to be built but that applies generally to all solutions. It will work pretty long time because CA certificates are issued to i.e. 20-30 years.
Basically our iOS app needs to communicate with a server which has a self signed certificate for now. In my app, the https is failing with untrusted server certificate which is understandable. The error is like this:
Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “my host name here” which could put your confidential information at risk."
So I sent the self signed certificate via email to the iOS device and imported into the profiles and hoping that it would be used as part of root CA for https authentication. To my surprise, it is not and I am still getting the same error. I think that iOS would be default to use root CAs at keychain to validate the server certificate and from what I read, the imported certificate at profiles are at keychain as well. So I could not understand why my imported self signed certificate is not used as root CA.
At this point, I don't really want to trust this self signed certificate via the coding like this iOS authenticate HTTPS with self-signed certificate or In iOS, how to connect to a server using https with self-signed certificate on the server? since this won't work in customer case where they would install our server on their network and they could create their own self signed certificate.
Somehow I didn't really get much information around this from searching. Could anyone shed some lights here and what I need to do to debug this? Thanks very much.
Update on July 15:
More update around this. I also tried to use configuration profile to add a self signed CA to root CA at the iOS device by following Adding Trusted Root Certificate Authorities to iOS , from my testing on 6.0 iPad and iPhone, it doesn't work as well. So not sure if that only works on jail broken device or not. In the end, I end up by allowing user to import a self signed certificate into the app. The app would load such imported certificate for certificate verification similar to this In iOS, how to connect to a server using https with self-signed certificate on the server?. Hope that it would help others in this case.
looking at the first tutorial you linked to you should be able to use that or some more advanced form of that and once you have tested and have it working then all you have to do for a client to create and add their own certificate would be to override/replace the localhost.cer file in the apps folder where the file localhost.cer "or whatever name scheme you use" is located. there are many ways to do this but one could be telling the app a link where the certificate is online for download and once downloaded, then replace.
Any questions I'll try and help further but hopes this helps you in the right direction.
I am implementing a push notification system for one of my apps, so I am following this tutorial and generating a SSL certificate for that.
This app of mine involves also, some exchange of data between the app and the server and I would like it to be SSL protected and I was wondering of getting a SSL certificate from verisign or other company like that.
My question is: is this SSL certificate created for push a regular SSL certificate, so in that can use it also to establish a https connection to the server (and save a couple hundred dollars to order a third party certificate)? I don't know much about SSL certificates, but I hope it can be used for that...
This will be amazing!
Since each certificate is tied to a specific domain, I'm not sure how this would work. There is a concept of wildcard certificates, but I still think they have to be for the same domain.
In your case, it sounds like you will have the Apple push certificate, which validates the connection between your server and Apple's push notification server. The other certificate would be to validate/secure the connection between your iOS app and your server. Both of these are assigned a different domain (gateway.sandbox.push.apple.com vs. yourserver.com).
One option you do have depending on how your iOS app is structured is to use a self-signed certificate between your iOS app and your server. I'm guessing the end-user will not be seeing the certificate anyway. This might be a way to save you money before deciding on a third party certificate.
I want to support HTTPS in my web application. Since the certificates from Verisign are costly, I decided to use openssl for generating certificate. Here is the link I referred https://community.jboss.org/wiki/JBossAS7ConfiguringSSLOnJBossWeb
When I tried to access the application in browser I got the error "The site's security certificate is not trusted". Here is the screenshot,
Please let me know how I can solve this error? Is it possible to use openssl in production?
The issue is that your self signed certificate is not 'trusted' by the browser. It does not recognise it as signed by one of the certificate authorities it trust.
You have two options - tell the browser it can trust the certificate or tell the browser that it can trust the entity which issued it (meaning that if you use the same certificate to sign other certificates; that those also get trusted).
See http://googlechrometutorial.com/google-chrome-advanced-settings/Google-chrome-ssl-settings.html for more information. Once you are in 'Manage certificates' you can import your own ones.
Every browser, every users, will have to go through those steps. So that is practical logistical limit on how much 'production' you can run with this.
Do check out the various 'free' certificates; they are very low cost.
MAC SOLUTION: The best way that I've found for manually trusting specific site certificates is to use Safari. See, when you manually trust a certificate in Safari, it requires you to enter your OS X account password. Safari does this because it stores the certificate details in Keychain Access, a system application that manages all vital data you store on your computer.
This is significant because Chrome also communicates with Keychain Access. Once the program has a record of the certificate being trusted by Safari, Chrome will also trust the certificate. You may have to restart the Chrome browser after activating the certificate in Safari to get this to work correctly.
Happy browsing!