Getting SSL to work

[upstage5]

In trying to enable SSL, I've made these changes to my catalog/includes configure.php

 

<<// Define the webserver and path parameters

// * DIR_FS_* = Filesystem directories (local/physical)

// * DIR_WS_* = Webserver directories (virtual/URL)

define('HTTP_SERVER', 'http://www.thewordinc.org'); // eg, http://localhost - should not be empty for productive servers

define('HTTPS_SERVER', 'https://thewordinc.c4.ixwebhosting.com/'); // eg, https://localhost - should not be empty for productive servers

define('ENABLE_SSL', true); // secure webserver for checkout procedure?

define('HTTP_COOKIE_DOMAIN', 'www.thewordinc.org');

define('HTTPS_COOKIE_DOMAIN', 'thewordinc.org');

define('HTTP_COOKIE_PATH', '/catalog/');

define('HTTPS_COOKIE_PATH', '/catalog/');

define('DIR_WS_HTTP_CATALOG', '/catalog/');

define('DIR_WS_HTTPS_CATALOG', '/catalog/');>>

 

and to my admin/includes configure.php

 

<<// define our webserver variables

// FS = Filesystem (physical)

// WS = Webserver (virtual)

define('HTTP_SERVER', 'http://www.thewordinc.org/'); // eg, http://localhost or - https://localhost should not be NULL for productive servers

define('HTTP_CATALOG_SERVER', 'http://www.thewordinc.org');

define('HTTPS_CATALOG_SERVER', 'https://thewordinc.c4.ixwebhosting.com/');

define('ENABLE_SSL_CATALOG', 'true'); // secure webserver for catalog module

define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT); // where your pages are located on the server. if $DOCUMENT_ROOT doesnt suit you, replace with your local path. (eg, /usr/local/apache/htdocs)

define('DIR_WS_ADMIN', '/admin/');

define('DIR_FS_ADMIN', DIR_FS_DOCUMENT_ROOT . DIR_WS_ADMIN);

define('DIR_WS_CATALOG', '/catalog/');

define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);>>

 

but still get the "you are not protected by a secure ssl connection" on the oscommerce administration page and find myself at http:// not at https:// when trying to shop.

 

Any suggestions?

[GemRock]

you are using a shared ssl which may not count as far as the lock in admin is concerned but you can always change a few lines of code to make it look good ie the lock is always LOCKED even when there is no ssl at all (you cheat yourself).

 

Ken

[upstage5]

I don't care about the lock icon, Ken. It's the fact that when I test it, the defaul shopping page, catalogue pages and checkout page are all unsecure.

[Guest]

Try this:

 

catalog/includes/configure.php

  define('HTTP_SERVER', 'http://www.thewordinc.org');
 define('HTTPS_SERVER', 'https://thewordinc.c4.ixwebhosting.com');
 define('ENABLE_SSL', true);
 define('HTTP_COOKIE_DOMAIN', 'www.thewordinc.org');
 define('HTTPS_COOKIE_DOMAIN', 'thewordinc.c4.ixwebhosting.com');
 define('HTTP_COOKIE_PATH', '/catalog/');
 define('HTTPS_COOKIE_PATH', '/catalog/');
 define('DIR_WS_HTTP_CATALOG', '/catalog/');
 define('DIR_WS_HTTPS_CATALOG', '/catalog/');

 

/catalog/admin/includes/configure.php

  define('HTTP_SERVER', 'https://thewordinc.c4.ixwebhosting.com');
 define('HTTP_CATALOG_SERVER', 'http://www.thewordinc.org');
 define('HTTPS_CATALOG_SERVER', 'https://thewordinc.c4.ixwebhosting.com');
 define('ENABLE_SSL_CATALOG', true);
 define('DIR_FS_DOCUMENT_ROOT', $DOCUMENT_ROOT);
 define('DIR_WS_ADMIN', '/admin/');
 define('DIR_FS_ADMIN', DIR_FS_DOCUMENT_ROOT . DIR_WS_ADMIN);
 define('DIR_WS_CATALOG', '/catalog/');
 define('DIR_FS_CATALOG', DIR_FS_DOCUMENT_ROOT . DIR_WS_CATALOG);

[upstage5]

Thanks, but that still doesn't work!

[GemRock]

sorry i scanned your post too fast but if you have no concern about the admin there is no need to post the configure.php at the admin side as you are only talking about the ssl at the store.

 

i think the configure.php looks OK if that is the way your host instructs you to use the shared ssl so there may be some other bits needed attention without looking at the files no more to say.

 

Ken

[Guest]

What I posted works for me - the only difference is that I don't use the $DOCUMENT_ROOT - I have a proper path in there.

 

Edit: just noticed you are running MS2 - I am running RC2A.

[germ]

In the includes folder (both for the admin and the catalog) there is a FOLDER named local.

 

See if there is a configure.php inside the folder named local.

 

If there is, it may have a line like this:

 

  define('ENABLE_SSL', 0);

You would need to change it to:

 

  define('ENABLE_SSL', 1);

[gaverp]

Kudos to the development community for this outstanding application!

 

From start to finish - 10 minutes!

 

Now for the fun part - configuring the cart to work for my specific application and needs.

 

I have installed the cart on a windows based platform (hostek.com) using MySQL and PHP.

Reference: www.AuthenticEndlessSummer.com

I am using a dedicated SSL certificate - not a shared one.

 

I too am struggling to get the SSL certificate and application to work correctly. I have incorporated the changes to the configure files noted in this thread - and now the Checkout / login links generate the https URL as expected.

 

However - during the page load - MSIE7 generates the warning message that the page contains non secure information. If I click "Yes" to display the non secure information - the lock icon does not show up in the browser. If I click "No" to the message to not show the non secured information - then all of the images and possibly the CSS style sheet are not shown but the Lock Icon appears.

 

I noticed in the online article for Installation tips that it mentions to enable the SSL option during the installation process. However, I did not see an option to enable SSL during the installation prompts and process. Did I miss something during the installation?

 

I also noticed that during the Server Evaluation process it reported that OpesnSSL was not enabled on my server - could that be the cause for the SSL problems I'm experiencing?

 

I have looked at the source code for the logon / checkout / include files and can not find any hard coded references to images / CSS sheets etc. so I'm baffled as to what might be causing MSIE to think the content is not secure.

 

Any help would be greatly appreciated.

 

Gaver P

[germ]

This thread may help:

 

Click Me

[gaverp]

Germ...

 

Yep - that did it.

 

As a result of the env variables being declared or named differently in Windows than Nix, are there going to be bunches of other contributions that are nix dependent on env declarations?

 

If so, then I'm thinking I should drop the win platform and migrate to nix to avoid future issues with "designed for" code.

 

eg. SEO optimization for URL's Titles and Meta tags; Authoriz.net integration; STS integration; shipping integration etc. etc.

 

Gaver P

 

ps. Incoming

[germ]

I've not heard of similar problems with environment variables on Windows platforms, but the possibility does exist.

 

Most contrib's don't use environment variables.

 

SEO optimization for URL's

SEO URL's use .htaccess files. They don't work on Windows platforms.

 

There may be an alternative, I'm not "up to snuff" on that subject.

:blush:

 

If it was me, I'd go nix...

;)

[vicster]

In the includes folder (both for the admin and the catalog) there is a FOLDER named local.

 

See if there is a configure.php inside the folder named local.

 

If there is, it may have a line like this:

 

  define('ENABLE_SSL', 0);

You would need to change it to:

 

  define('ENABLE_SSL', 1);

 

I'm very curious about these folders. What are they for? Both of mine have a single file called README which say:

 

This directory contains local configuration information.

 

It also must contain a file named configure.php that can be used to override

the defaults set in application_top.php

 

Remember to execute PHP commands the file needs to start with ?php and end with ?

 

(I took the brackets off the end so they wouldn't do anything 'bad')

 

Just curious...thanks!

[germ]

If you read the README text you have your answer:

 

It also must contain a file named configure.php that can be used to override

the defaults set in application_top.php

:blush:

 

Developers use these folders for configure files for use in site development, then remove them after the site it finished.

 

That's the most likely scenario I guess...

 

I've also discovered that many "automatic" install programs on servers write configure files here.