Home → Support →

SSL & Certificates - Generating CSR

• Edit

opspark

19 Apr, 2011 06:47 AM

Hey guys

I am trying to set up SSL for an app. According to instructions on http://support.appharbor.com/kb/tips-and-tricks/ssl-and-certificates I need to upload the private and public keys or pfx file.

However, don't I need a CSR (Certificate Signing Request) for the server (I don't completely understand SNI SSL) that the app will be deployed to? Only with that can we generate a valid cert.

I was using a self signed certificate generated by IIS for development purposes on my localhost. When I upload that cert to appharbor (not really expecting it to work) and then I navigate to the app, besides the warning about the cert being issues to a different machine, i also get an error about the app not "redirecting properly"

Chrome: This webpage has a redirect loop
FF: The page isn't redirecting properly

Any ideas as to what the issue might be?

Thanks
Jaspreet

1. Support Staff 1 Posted by rune on 19 Apr, 2011 05:57 PM

   

   Hi Jaspreet,

   SNI SSL works the same way as regular SSL except it has limited browser support. You don't need an CSR from the actual server that the certificate will be installed on - but you do need to make a CSR based on the private key that you want to use. When you've created a CSR you send that to a certificate authority (such as rapidssl.com) and they'll send you a certificate. The certificate is the public key and as you already have the private key you're able to upload these to AppHarbor. The CSR itself isn't used for anything except for giving the certificate authority something to create an certificate from.

   Note that the pfx files that you can export from IIS contains both the public and private keys. As soon as you've completed the certificate request in IIS you can export the certificate and upload to AppHarbor.

   When you use a self signed certificate you're effectively the certificate authority. This causes warnings to occur in browsers as you're not a trusted authority and the issuer can't be verified by the browser. Usually these errors say something along the lines of "The certificate/site can't be trusted" and lets you add an exception so you can browse the site anyways. As you say, this is obviously not something you want for production use - even though the data is still encrypted with SSL you don't want the users to be bothered with that kind of warnings. In your case I suspect it may be related to your OS version - I went to your site and had no issues, except for the warnings, when accessing it with HTTPS. What OS and browser versions do you currently use?

   Best,
   Rune

   • Edit

2. 2 Posted by opspark on 19 Apr, 2011 07:33 PM

   

   Hi Rune,

   Thanks for the explanation.

   I am using Windows 7 Home Premium and I see the issue in Chrome 10, Firefox 4 and IE 9.

   After you mentioned that it works for you, I dug in a little deeper, and found that whether I go to http://creditcardverification.apphb.com or https://creditcardverification.apphb.com I get a 302 to https://creditcardverification.apphb.com.

   Here is what one of the redirect responses looks like

   HTTP/1.1 302 Found
   Server: nginx/0.8.54
   Date: Tue, 19 Apr 2011 19:25:07 GMT
   Content-Type: text/html; charset=utf-8
   Connection: keep-alive
   Cache-Control: private
   Location: https://creditcardverification.apphb.com/
   Content-Length: 158
   
   Object moved
   Object moved to https://creditcardverification.apphb.com
   

   And so there is a never ending redirect loop being created.

   My controller is tagged with [RequireHttps], which is what causes the first redirect (from http to https) but why is it also redirecting https? Furthermore why for me and not for you? My machine is the one the certificate came from so that's one difference.

   Thanks again!

   Jaspreet

   EDIT: Fixed the *apphb.com links to not have www prefix

   • Edit

3. Support Staff 3 Posted by rune on 19 Apr, 2011 07:50 PM

   

   It actually worked when I tried the site earlier today - now I get the redirects too. I think the problem may be related to the use of the RequireHttps attribute. For some reason that attribute doesn't support the X-Forwarded-Proto header, which is used by the load balancer to indicate that HTTPS was used.

   I've previously covered this in another discussion and you can use the code that I'm refererring to (the gist) in there: http://support.appharbor.com/discussions/problems/401-requirehttps-... .

   I believe the redirect issue is related to the fact that IIS doesn't recognize that HTTPS is already used. The thing is that SSL is actually terminated at the load balancer level and it requests the individual web servers using regular HTTP. As such the X-Forwarded-Proto is necessary to indicate that HTTPS was used - this is the way we use HTTPS on appharbor.com, so I think that's the reason the issue occurs for you and not us.

   I'll make sure to add this to the knowledge base article as soon as we get the issue you're experiencing resolved.

   By the way, the links you provided doesn't work because you site doesn't automatically get *.apphb.com hostnames with the www prefix.

   • Edit

4. 4 Posted by opspark on 19 Apr, 2011 09:33 PM

   

   Gotcha. I made the change to use the attribute from your gist instead of the regular RequireHttps one, and that worked like a charm. Now the application works as expected on AppHarbor.

   Thanks for all your help!

   • Edit

5. Support Staff 5 Posted by rune on 19 Apr, 2011 09:43 PM

   

   That's great! I've updated the KB article so other can benefit from this too.

   Thanks,
   Rune

   • Edit

6. rune closed this discussion on 19 Apr, 2011 09:43 PM.