If the website at YOU.pagekite.me displays the Apache welcome page, but you cannot access any content, you may need to edit your virtual host configuration to recognize your PageKite name as well as the localhost default.
In some cases, adding these lines to httpd-vhosts.conf may help:
ServerName YOU.pagekite.me
ServerAlias localhost
(Replace the default ServerName settings with these lines.)
In other cases, you may have installed a 3rd party application which has it's own configuration file and a VirtualHost directive which does not match your kite name.
On Linux, the following command may help find some clues:
$ grep -r -e VirtualHost -e ServerName /etc/{apache2,httpd}
Similar to the above issue, CMSs such as WordPress and Status.net may also be providing local URLs instead of your PageKite URL. This addressing this is system-dependent, in Status.net it is the
$config['site']['server']
variable in statusnet/config.php.
If your website's URL ends in .pagekite.me, then you should be able to use the service's wildcard SSL encryption without any extra effort. However, note that this will only work for pages with exactly two dots in the domain name. So these names are fine:
But these will not work:
If your website's name does not end in .pagekite.me, then you will need to provide an SSL certificate of your own and rely on your users to have modern browsers which support the SNI extension of the TLS protocol.
Recent versions of the following browsers are known to work:
The following are do not properly support SNI and will not be able to visit your encrypted site:
If you visit an https:// page and get a security warning or the lock icon appears to be "broken", it may be because you are including images, javascript or CSS from unencrypted sources. Browsers will not consider a page secure unless all elements on the page come from secure sources.
To check if this is the case, you can use the "view source" feature of your browser and search for http://. If it is found in any src= attributes, you will have this problem.
Some popular software packages, including Wordpress, used hard-coded URLs and may redirect users away from the encrypted site if they have been configured with a normal http:// URL string.
Double check the settings of your software and make sure that all URL paths are configured to use the secure https:// scheme.
It is common for web sites with their own SSL/TLS support to attempt to redirect users which access insecure versions of the site. This can in turn clash with the .pagekite.me, wild-card based encryption, causing an infinite loop of redirection that never successfully completes.
This is because when using the PageKite wild-card certificate, only the connection from the browser to the PageKite front-end relay is encrypted, the traffic seen by your local web-server is plain-text HTTP (although the PageKite connection itself is encrypted, your web server has no way of knowing that).
This problem can be resolved in two ways:
If you already have a local SSL certificate (some systems, such as Yunohost may generate one for you) and an HTTPS-enabled web server on port 443, you can implement solution 2) like so:
pagekite.py --add 443 https://yourkite.pagekite.me/
This will add an HTTPS kite to your ~/.pagekite.rc configuration. If your configuration is in /etc/pagekite.d, then you should instead add a line like this to /etc/pagekite.d/80_httpd.rc:
service_on = https:@kitename : localhost:80 : @kitesecret
If you are having trouble configuring your integrated Debian or RedHat package, take a look at the troubleshooting section on the ConfigureYourSystem page.