How to restrict access to GitHub Pages with client side SSL certificate?
For example, I want to have https://username.github.io/ for public access, and https://username.github.io/secret_place for only connections with ssl client sertificate.
Is it possible? If yes, how to configure it?
Github pages is a static site only, and does not support any server-side code https://help.github.com/articles/what-is-github-pages/
Essentially github pages are static site hosts only, and do not include routing rules, or any verification of client certificates.
I can't say with certainty but I'm pretty sure this isn't possible in github pages. It isn't really the github pages designed use case.
Related
I have a Flask API which has no database but just a json file that stores the data. At the moment I have put it on an EC2 and opened a port so someone can put in the IP address and port and have access to the API that way. The problem with this is that I get a mixed content error since the site it uses is HTTPS and the API is HTTP. I want to put the API behind HTTPS on a proper platform but I'm not sure where to start.
Is there a platform that I can host the API python file and the json file behind an HTTPS?
All of them? EC2 allows HTTPS (per #tawfikboujeh's comment). I don't actually know a hosting platform that would allow HTTP but not HTTPS.
There are some options in how you accomplish this:
Use a self-signed certificate. This will give you HTTPS but all the modern browsers will give a nasty warning to all your visitors.
Purchase a signed certification for you IP address from a CA. Just hope you don't have to change your IP address.
Purchase a domain and use Let's Encrypt to generate a signed certificate for you.
Option 3 would be the most robust solution, but it does carry the cost of a domain (maybe $10/year).
Google App Engine is perfect for this. SSL cert is free, and you would be in their free tier.
https://cloud.google.com/free
Recently installed a SSL Certificate on my webserver for our new website. Now I'm building the website and want to use ogp.me, but they only offer a non SSL http link.
Will this affect the security of my website?
Our website does not have any 'secrets' or sensitive information, only a contact form.
If <html prefix="og: ogp.me/ns#"> is your only http reference, then no, that link will not affect your security.
In fact, that link is really an Open Graph namespace declaration, that is it's just the name of a namespace, not an URL at all even if it looks exactly like one.
Could someone explain the steps that one must do to show an Azure application (example.cloudapp.net) in a custom domain (service.example.com), when we want to use a secured connection? So the users browse to https://service.example.com, see it as a certified, trusted domain, and can safely access the application.
Right now, I think that
1) we need a domain (and subdomain) with a static IP from a service provider
2) we need a certificate from a CA for our domain
But I'm not quite sure how the connection between our domain and cloudapp.net should be made. I have found many examples and blog posts, but they tell either how to install a certificate to Azure application or how to show the application in custom domain (without the certificate).
This sounds like a basic requirement, so I'd expect a rather simple solution to exist.
Thanks!
Look at this blog entry
Custom Domain Names in Windows Azure
Basically you need to buy domain name and add some CNAME record in DNS table. The part remaining would be to buy appropriate SSL certificate for your site.
Here is a stop-gap for custom domains: http://www.bradygaster.com/running-ssl-with-windows-azure-web-sites
I do not believe that Azure currently supports using a certificate with a custom domain (see request for feature). In the meantime, you can use CORS.
We have a multi-tenant website where we use a wildcard SSL cert to give people a subdomain to our site. Some of our customers would like to use their own domain, but I'm concerned about how we would manage each customer's certificate as our business grows. Currently the certificate resides on the web server, which means loading all of the certs to each web server as we add them.
I'm aware we could introduce a dedicated SSL device in front of the web servers, but are there other options to improve the management of these certificates?
I'm a Microsoft Technical Evangelist and one of my partners had exactly the same challenge.
I have created a sample source code that automates and manages SSL certificates for multiple domain bindings using a new IIS 8 (Windows Server 2012) feature called SNI, which is a kind of SSL hostheaders.
All you will need to do is to reuse my code (it's quite simple) and upload your custom SSL certificates to the blob storage, or you can write your own provider to fetch custom domains and certificates from your database.
I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/
You could make your clients deal with their own certificates and make them run there own https site. They can serve a page containing a single frame with your content (over https). The users will see their domain and their certificate and the browser will load the frame without complaining as long as the frame contents are also loaded over a valid https connection. I created a quick an dirty test page so you can see it in action.
This solution will 'break' the address bar as it will keep the url of the page containing the frame. Depending on the type of site you're running this might be a showstopper.
I have a website with only home page available through simple HTTP protocol.
All other pages are accessible only through HTTP over SSL(https://).
I'm using CDN for home page and very happy with it.
But for me it looks like using CDN for https pages is impossible because of security warnings, especially in IE. My files hosted at CDN are accessible though simple HTTP protocol.
What should I do? How this problem can be solved?
You need to get a CDN that supports serving files over HTTPS, then use that CDN for the SSL requests.
You can do this if their boxes have HTTPS support. What you can't do is use a subdomain of your own domain to cname against the cdn network. Because SSL doesn't work this way.
so https://cdn.tld/mydomain/path/to/file as a mechanism does work (because browsers will verify the cdn.tld ssl certificate correctly)
but https://cdn.mydomain.tld/path/to/file will not.
Two options, but in general I'd redirect all pages that don't need to be SSL'ed to their non-SSL equivalent and only use SSL when necessary.
Get a SSL certificate for your CDN host. It's just 30 bucks/year, but you need to take into account that this requires more configuration and depending on the traffic, this is also more expensive because the server requires more resources for SSL'd connections.
For the relevant pages, store the CSS/images/js files "local" on your own SSL host and use them when you need SSL. Of course you loose the speed etc. from the CDN, but that's a trade off. We opted for this because just our signup is SSL, 99.9999% of the time users spend on our website is on non-SSL links.