Where does ISPConfig expect to see server and private kys

Not that I'm aware of. How would I check?

 

The crt, scr etc are your certificate, signing request and key files, so they're all there. You can check the /etc/apache2/vhosts/vhosts_ispconfig.conf file as well.
That'll have a section for your website that starts

<VirtualHost ip.ad.dr.ess:443>
ServerName www.yourdomain.com:443


and a bit further down should be

SSLEngine on
SSLCertificateFile /var/www/webXX/ssl/www.yourdomain.com.crt
SSLCertificateKeyFile /var/www/webXX/ssl/www.yourdomain.com.key

listing the files you just mentioned.

If you were using suPHP you would have consciously installed it, If Suexec is installed I think it gives you an enable 'tickbox' in the ISPConfig website setup.

A drastic check is to enter

a2dismod suexec

If it was enabled, that will disable it, an error message means it wasn't.

a2enmod suexec

would re-enable.

After all the to and froing with the certificates, it's probably a good idea to restart the web server explicitly as well.

/etc/init.d/apache2 restart

 

Looking at the output from the first two commands, Inotice all of it looks OK to me. othername in the first one (i.e. without the www.) is unsupported and there is no date or challenge password attribute for the second, but I have no idea if that makes any difference to how the site would render in a browser.

So the question is are those four suffixes OK, or must there be a .pem somewhere to make it all work?

 

Having done all that and checked everything, the browser is still getting exactly the same responses as before.

Suexec was enabled so I disabled it. There's a tip to run /etc/init.d/apache2 force-reload to fully disable. but if temporarily disabling doesn't achieve anything is there any point?

Apache2 restarted without any error messages at all.

 

Pem files, .crt and key files are equivalent, just that a pem file can contain certificates or keys, ISPConfig just happens to use .crt and .key.

While a force-reload is the suggestion, restart achieves the same thing.

In a vanilla Apache install, the server runs the website as the 'Apache' user, usually on Debian or Ubuntu a user called 'www-data' or on some systems 'nobody'.
Under Suexec, that is changed to the local website owner, under ISPConfig usually web1_admin or similar. While this is good from a website mail point of view as mail servers tend not to like mail from 'nobody' it does impose tighter constraints on the 'ownership' of any files on the website. i.e. If you check the file owner and group, they should correspond to the user you have specified as website admin under the users and email tab.
File permission settings vary slightly as well.

.htaccess files can also play havoc with setting up SSL, as well as Zen Cart mods like SEO urls that use mod rewrite. They can be temporarily renamed fredhtaccess or htacess.bak or whatever.

But if the crt and key files are there and correctly formed, and there is a corrsponding entry in the vhosts.ispconfig.conf file that correctly references them, you should have SSL operational.

It is usually a good idea to clear your browser cache as well as they have a nasty habit of using cached pages when doing this kind of testing.

 

Cache cleared. All .htaccess files under that web# renamed to .htaccess.orig suexec disabled everything else seems to check out and I have a nasty -12263 error still when entering https:// in the address bar and not found when entering http://

Is there a next move? Or is my poor shopping cart ( I have another one to install shortly, for a client this time) to wander through the ether unseen in perpetuity?

 

Check the web error log in /webXX/log, same level as the ssl folder for any nasty messages there.

And while I think about it, what browser are you using for this? There have been reports of Firefox 2.0.0 and up doing this with some openssl certs.

I just tested on the ISPConfig/Debian VM image, which has Suexec running, and ZC 1.3.7. Generated a certificate, enabled SSL in the config files, and off it went, no problems at all.

 

No logs have been posted in /web#/log since Saturday 13th, when I first tried installing the cert!

Also, I'm using FF 2.0.0.6 on Ubuntu Feisty.

Yes, suexec doesn't appear to have had an effect, on or off. It's off at the moment.

<edit> May be FF behaviour, but ISPConfig has a self-generated cert for the overall server. On this domain, it hasn't worked with either CAcert or self-generated. </edit>

 

Have a look here, might be worth a try, comments there have some further info

http://ffextensionguru.wordpress.com/2006/10/24/firefox-20-ssl-2-tweak/

 

Movement! Instead of the -12263 the browser says The connection was interrupted - any change is encouraging at this stage.

So FF was at best masking any attempts to fix it.

 

I've been experiencing the same problem. And changing security.enable_ssl2 to true in about:config in firefox changed my problem from getting the error message mentioned earlier, to firefox default error message:

Code:

The connection was interrupted

The connection to test.domain.nl was interrupted while the page was loading.

    *   The site could be temporarily unavailable or too busy. Try again in a few
          moments.

    *   If you are unable to load any pages, check your computer's network
          connection.

    *   If your computer or network is protected by a firewall or proxy, make sure
          that Firefox is permitted to access the Web.

What would be the next step in trying to resolve this issue? I have followed all the steps in this forum. I want to use a self signed certificate but I just can't seem to get it to work.

 

Have you tried to recreate the certificate?
http://www.howtoforge.com/forums/showthread.php?t=121