Pin5 Posted November 4, 2010 Share Posted November 4, 2010 I am about to purchase an SSL certificate for my shop. My host allows you to choose the address to which the certifcate will be applied (such as "www.mydomainname.com"/ or "secure.mydomainname.com"/ "order.mydomainname.com", etc the "www."/ "secure.", etc prefixing the domain name. My host is Heart internet. Could someone please advise me if I just request the certificate be applied to "www.mydomainname.com" or if this would cause any problems and should I make the secure areas addressed as "secure"? Any advice appreciated as I am new to this whole SSL thing!Thanks for any help someone more experienced in this can give me. Link to comment Share on other sites More sharing options...
mytheory. Posted November 4, 2010 Share Posted November 4, 2010 I don't know if this can help ya, but when we got our ssl certificate the common name (or URL address) we used was mydomain.com (however, our CA gave us both http://www.mydomain.com and http://mydomain.com). But if you have to choose one or the other go with the address name that is the same as your shop's home url.We used http://mydomain.com, because as part of our "branding" attempts for our shop we did NOT want to include the www. infront of our web address. So all requests to www.mydomain.com is redirected to mydomain.com for us and the reason we chose this as our ssl cert url. I wouldn't use a subdomain like the ones your mentioned in your post unless you want to limit ssl access to those subdomains. But using your base shop url should cover all of your site.HTH! Link to comment Share on other sites More sharing options...
Pin5 Posted November 4, 2010 Author Share Posted November 4, 2010 Thanks for your reply.I have a redirect setup so that any requests for "http://mydomainname.com" goes straight to "http://www.mydomainname.com". I was thinking therefore of choosing the "www." prefix, but was a bit confused by the other prefixes offered by my host (such as the ones I mentioned "secure." "order.", etc.I guess I'll opt for the "www." prefix and hope things work from there! (Fingers crossed!) I understand the redirect, but, as I said, I am new to SSL certs and how to apply them, so any advice is much appreciated. Link to comment Share on other sites More sharing options...
mytheory. Posted November 4, 2010 Share Posted November 4, 2010 I'm fairly new to all this too... but ithink those subdomain options are for those who might redirect their checkout process to a subdomain or another server (using the subdomain) to handle their checkout process.However, since for us (and sounds like for you too) we just use our main website url and just need to create a secure connection to our processor or paypal we didn't want to go through the hassle of handling any payment data (for security reasons) or setting up another secure server. For most webshop's that don't handle their own payment methods a ssl certificate for yoru main domain should work. Link to comment Share on other sites More sharing options...
Pin5 Posted November 4, 2010 Author Share Posted November 4, 2010 I am planning to use Paypal as the payment gateway, so I am looking to secure the register/ login area for any customers to the site (I know that some people advise that if you are using Paypal then you don't really need an SSL cert, however, I'd like any customers to feel confident in the register/ login area too, as I know this can be important when you are inputting personal information such as name/ address, etc).Thanks again for your reply and advice. This whole SSL issue can be very confusing for a beginner! I think I will go with the "www." prefix and no doubt will be posting back here soon for further advice! Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 You should be choosing the prefix that is consistant with the rest of your site. so, if you have a www.yourdomain.com your ssl should be set up that way. or if you have no prefix set it up without the www.Good LuckI disabled my store ssl but have it running on that domain so i figured its covered Link to comment Share on other sites More sharing options...
mytheory. Posted November 8, 2010 Share Posted November 8, 2010 Bubba,If you don't have SSL enabled on your site.. then your SSL certificate is not doing its job. It actually won't do anything, so no information would be passed over a secure, encrypted connection. Basically, if the page isn't being served over a https:// connection than its not secure whether you have basic or even EV ssl certificate.I highly advise you setup your SSL certificate (which it seems like you already have) and then enable it on your shop. One other alternative is to enable (force) ssl across your entire site, but it may slow down some pages unnecessarily. Like do you really need to pass product information and images over a secure connection, when its public information anyways? Also, after enabling the ssl, go to the ssl enabled pages (ie. account register/login, checkout, cart, contact us, etc.) and make sure that your browser (ie or ff3) doesn't throw any "unsecure data passing through a secure connection" errors. If you see those, you need to make sure everything on that page including images are being passed over a https:// connection.HTH! Link to comment Share on other sites More sharing options...
jackso11 Posted November 8, 2010 Share Posted November 8, 2010 Just dug up this post.I have enabled SSL on my site, and with my hosting company. Now it asks me if I want to display only secure items, if I say no the page loads correctly but not secure. If I say yes al the images don't load (thumbnails, animated bits, logo).How do I get around this and make all my images load through https: ? Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 Well what i was thinking was even though my store doen't have ssl enabled as soon as someone checksout it automaticly goes to htts connection. So the only time it's not ssl protected is when the visitor views pages. I originally disabled it that way because when the visitor went to checkout a pop up appered and images didn't display right and it was slower. If I do what you suggested things will just go back to that and it's really not a good viewing experiance for visitors plus the popup could scare potential buyers away. I know it would be better to enable it, it's just not user friendly ya know? Does it make a huge security differance if when a visitor checksout the ssl is handled by the the gateways that are doing the transaction? AM I Acting stupid not to enable it? Could that lead to a potential disaster for my store?-----------------Another thing is I have two stores my main store it's not enabled and thats what we are discussing. However my demo store has ssl enabled and it's the newest version of prestashop. It works like a charm and you don't get the pop up ssl warnning, the images are fine and one would never no they are on a secure page. How can I do thins with the main prestashop store witch is version 1.3.1. Here is the link to the demo store SPAM Link to comment Share on other sites More sharing options...
mytheory. Posted November 8, 2010 Share Posted November 8, 2010 Those are good questions.. and here's how I think about them.If you are a business handling monetary transactions over the net, I think you absolutely must have SSL enabled. The one exception (although I still think having a SSL connection is worthwhile) is if you are only using PayPal. Since when using PayPal, the customer is redirected to PayPal's page (which uses a EV SSL Certificate) some people say that you don't need a secure connection and the module works without a SSL Cert. However, I think you still do since although payment data is handled by PayPal if any other personal information including email addresses are passed onto PayPal (for verification) it should be over a secure connection. From my understanding, although Google Checkout handles payment data similar to PayPal, the module requires you have a SSL to properly work.If you are using a payment gateway, a SSL Certificate enabled over a secure connection it is absolutely without a doubt necessary, and should not be overlooked. This is because payment data including (and probably most importantly) the cardholders name, address, and credit card information is all entered on your site through the gateway module before it is sent to the processor for processing. And this information while being entered and transmitted needs to be encrypted.For other SSL pages like the account registration and login, follow similar ideas as having or not having SSL for PayPal. Personal information might not be as important as payment data, but if I was a customer I would like to have the piece of mind that my information (including personal stuff) are kept safe from prying eyes. IMO.The good thing about PS is if you enable SSL in the BO it will only enable it for certain pages, so it doesn't slow down other pages that don't need to be secured (as you probably already noticed). And yes, those warning popups can scare away customers that is why it is important that everything on those ssl-enabled pages are being passed over a https:// connection. So my advice is to enable SSL for those pages, but also to get rid of those errors. Don't sacrifice one for the other. You want both ssl and a user-friendly environment.From my experience, those warnings more often than not are from images on that page. For example, when we first setup our shop with ssl we got one of those warnings. After spending some time looking through code and disabling/enabling certain modules on those pages, we found that we had one error from our category block. We use a third-party category module that shows an arrow for categories with subcategories. Little did we know that those arrows were actually image files. I forget the actual syntax, but the module's code was pulling this image from an image folder within the module, so instead of using that same path, we changed to full URL (ie. https://mysite.com/modules/blockcategory/imagearrow.gif). So instead of being sent as a regular image file from a module folder over unsecured connection like the rest of the site, we specified it be sent over a secure connection... ie. the https:HTH! Link to comment Share on other sites More sharing options...
jackso11 Posted November 8, 2010 Share Posted November 8, 2010 That is what I thought at first, I am using paypal so it directs to a secure payment page anyway with green bar and padlock. However, when a user logs in to the site I think it is important that SSL is active as they have an account, account details, address's, orders, etc. It should all be protected.So, how can I get the images to display?Sorry i am a novice. How do I specify it to pull the images from a specific location like that? Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 Thanks for taking the time to give your thoughts on this! The main issue why i disabled ssl is because of the pop up visitors that don't understand it witch i have a lot just leave and who can afford that? lol So, if i am understanding you right I need to go through each module i have installed to figure out witch one is causing the warnning pop-ups ? There is two now that i notice the first is the one that says "do you want to view this page in secure or non-secure mode" the second is more like a warning witch is more scary looking then the first lol. Is this also caused by the same thing? and can both of them be sorted out and not display when ssl is enabled correctly? I don't want either of them to display if thats even possible. Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 jackso 11- I think you have to correct the address to the images and add the https into the address line. Thats what he said he did to fix his issue. Link to comment Share on other sites More sharing options...
jackso11 Posted November 8, 2010 Share Posted November 8, 2010 but what happens if its an image that is used on a non secure page as well as a secure page. putting https in the link would make it not work, right? Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 From what i understand regular images that you add to the site and the ones that come with the shop don't need to be https and when you enable the ssl in the back office it is for only certin pages like customer account and order pages. In his case a module installed was causing an issue so he changed the image path. In my case I have no idea whats causing the pop ups and need to figure it out because a module of mine could be also causing an issue. I think there is a page init.php that you can edit to help fix this issue I read something about it months ago but can't remember everything i was reading I am going to look for the forum post I read months back and see if it can help. Link to comment Share on other sites More sharing options...
Guest Posted November 8, 2010 Share Posted November 8, 2010 I found the tread i read months ago maybe this can help you. http://www.prestashop.com/forums/viewthread/19232/I also found this about prestashop witch was a good read half way down they talk about ssl http://www.packtpub.com/article/security-disaster-recovery-prestashop-1.3 Link to comment Share on other sites More sharing options...
mytheory. Posted November 8, 2010 Share Posted November 8, 2010 jackso, if you are certain that image is throwing the unsecured error... you need to change the code so the path to that image isn't just to the module or image directory (as an example), but it is over a secure connection. Ithink in some cases you can use {$base_dir_ssl} instead of {$base_dir} to initiate the directory path. If I remember correctly, for the module that was causing our errors this usual fix didn't take... so hopelessly I just used the full web address to pull the image and it worked. Basically, you can pass anything over a secure connection by just telling it to use SSL (or https: instead of the usual http: header), its just that not all information needs to be over a secure connection. To see for your self, you can even move the image to the root directory... and point your browser to http://mysite.com/image.gif and it should show you that image. Also, you can pass that same image over a secure connection by pointing your browser to https://mysite.com/image.gifBubba, yes you are correct. In most cases the error is caused by an image and/or module. From my understanding, the default modules and layout shouldn't cause any warnings. If you have any third party modules I would disable each one, one by one, to determine which module is causing the problem. Once you know that you can look through the code of that specific module to make sure links are being passed over a secure connection as well as any images that might be causing issues. It's important to note that you might have to change some of the links on those "SSL" pages to link to a secure base dir... just like the above paragraph, those fixes are easy... if you see a link on those pages that start with {$base_dir} change it to {$base_dir_ssl}. Another way that might work is if you know what module is creating the errors, you could exclude them from certain pages, but still have them appear everywhere else. To do so, go to modules tab, positions, then transplant a module. You should see a text box before the add button, you just enter the pages you want the module excluded from.FYI... we have 2 modules that appear on every page, they are the best seller and specials block modules. They have been modified, but they still pass product images and names, but we never got errors from these blocks for some reason. We didn't have to change the product images to point to a secure connection or anything, they just worked. Oddly, an arrow image that was being called by javascript by the module caused our 1 and only error. So although I'm not 100% on this, but I don't think you should have to worry about product images in those blocks, but if all else fails, check them too.HTH! Link to comment Share on other sites More sharing options...
Guest Posted November 9, 2010 Share Posted November 9, 2010 Thanks mytheroy for taking the time to help sort this out! I am going to work on it a little and see how it comes out! I'll post my results later. Thanks again Link to comment Share on other sites More sharing options...
Pin5 Posted November 10, 2010 Author Share Posted November 10, 2010 TommyGunn - thanks for the reply. I am planning to set this up with the "www." prefix as this is what I am using for my site (with a redirect from any non-www traffic to the www version).Fingers crossed! Link to comment Share on other sites More sharing options...
Guest Posted November 10, 2010 Share Posted November 10, 2010 pin5--If you have to choose between www or no www go with the one that is the same as your domain. If you domain has a www before it choose that one. When i got mine they told me it covered both www and non www versions of my domain. You might want to check that out with the company your bought it from. Link to comment Share on other sites More sharing options...
mytheory. Posted November 10, 2010 Share Posted November 10, 2010 Yea I agree with TommyGunn...Our first SSL certificate from Verisign didn't cover both www and non-www. We were redirecting all http requests to non-www for our site so that was our "main" url address. So we used that one. However, our second one was from Comodo (who I highly recommend) gave us a certificate that covered both.HTH! Link to comment Share on other sites More sharing options...
Guest Posted November 10, 2010 Share Posted November 10, 2010 I think godaddy offers 2 types and I think you might be able to get it for a good price too. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now