I'm not very learned on ssl and certs in general as I have only recently started "really" working with them and understanding them. I have an issue.
I'm shipping a library for android which connects to a specific domain "derp.com". Each of my customers get a subdomain to access with the library. EG "customer.derpy.com"
So working with https on android can be a pain but its not the end of the world. I'm having issues where my cert isnt being trusted by all of the devices using the https of the server.
I suspect this is why:
heroku certs --app my-app
Endpoint Common Name(s) Expires Trusted
------------------------ ---------------------------- -------------------- -------
cdepy412532.herokussl.com *.derp.com, derp.com 2013-04-05 22:36 UTC False
The certificate is being marked as untrusted. I suspect this is the cause of the issue as the devices are complaining that they cant verify the certificate. Why would this be?
The certificate is issued by a ca. I think its either rapidssl or geotrust.
I do hate answering my own question and would rather delete it but this may help someone else.
The issue in my case is that I had forgotten to combine the intermediate cert with the root cert.
This tutorial by Ryan McGeary was a great help.
My only advice is make sure you have the intermediary certs (pem or crt), root certs(pem or crt) and private key(key) from your boss or whoever received them. If you do not have all of these then you will get an untrusted cert on heroku.
Related
I'm using Ruby on Rails and AngularJs in my app. I deployed to https://myapp.heroku.com and everything works fine.
Now I bought a custom domain at GoDaddy.com and I set it up with Heroku to redirect to my app. Works fine. The problem is, instead of using HTTPS is using HTTP.
What are the steps to change this? I looked a few tutorials but they seem old and not updated.
According to Heroku the SSL certificate is automatically managed. Do I need to buy a certificate at GoDaddy.com?
Yes, you'll need to get SSL certs from godaddy or some other providers.
Then
go to your app settings in heroku
Look under "Domains and certificates" section
Configure SSL button.
Now just follow the steps and you'll be done.
When it comes to SSL these days, do not run out and purchase one. It can be a waste of your money if you have the skills to set up auto-renewal with Let's Encrypt.
I would recommend checking out SSL Endpoint and Automated Certificate Management from Heroku on setting up and automating the SSL process. There's a lot of information in there and will help keep your costs down.
If this is a bit complicated or you would prefer another plan of attack, you can also use the Let's Encrypt Plugin for Ruby on Rails
Also, don't forget to turn config.force_ssl = true on in your config/environments/production.rb file. This way, Rails will redirect all HTTP traffic to HTTPS. If you would prefer the browser to do the redirects instead of the server, you can have Rails, since you're on Heroku and not a customer Nginx server, respond with a Strict-Transport-Security header; added link so you know how to configure this guy appropriately in regards to your application.
Yes, most web hosting companies require you to purchase an ssl certificate. In the case of GoDaddy.com, check out their ssl certificate page.
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 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.
If you auto-enroll an account for an X.509 certificate in a Windows PKI environment, do you get the same certificate (and, by extension, private key) on every computer in the domain that you log into, or does a different certificate get issued for each computer you log into?
I would expect there would be a single certificate that would appear in the CurrentUser certificate store on each computer you logged into. But this is a matter of dispute and I don't have an environment where I can test it.
Are there any subtleties of configuring the certificate template that affect this? Does not using roaming profiles affect this?
If it matters, I am most interested in how this works for service accounts, but I expect it would be the same as for interactive user accounts.
Our PKI is currently Server 2003. It should be migrated to Server 2008 within a year.
Win2K3 does support something called "credential roaming". I haven't investigated it myself, but did come across a document explaining it: http://technet.microsoft.com/en-us/library/cc700848.aspx
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.