Forum Moderators: phranque
What is a private key, CSR, CRT... how does a webmaster create pages that are hosted as "https"?
The private key is a private code used to sign a certificate; if you want to do internal communication, use this. If not - your certificate issuer will use his own in order to sign the certificate (this is a good idea if you want users to go to https:// pages without warnings)
The CSR is what you need to start with, it's like a 'blank form' you have filled in. You take that to the certificate issuer, and he will sign the form with his private key, so that those who trust him will trust the certificate signed by him.
The CRT is the certificate itself; your server needs this. It may also need some CA certificates, which relate to the certificate granting guy and establish his chain of trust.
Most certificate issuing outfits will talk you through the process fairly well. A well known domain name firm has a good walk-through for major server/control panel types.
I think you are then good to go. If not, then I'm sure someone will correct me.
As I said, I haven't used SSL, but I do have a code signing certificate that cost $99. These are typically issued by the same authorities so believe me when I say you should shop around. All certificates are equally secure but some authorities charge much more than others. I believe the certificate does no more than enable public key encryption on the server (accessed through https: instead of http:) - I'm not sure there's any need to get more involved than that.
Kaled.
Now there's a folder in my root called "ssl", and in there is a new file called "[example.com].crt"
At that point I thought I was finished.
There's an image on my site at "http://www.example.com/images/logo.gif" which is sometimes displayed on secure pages. Since it's not hosted securely, the browser alerts the user and warns them that not all the items on the page are secure.
So I figured, since I have a certificate now, I could go to "https://www.example.com/images/logo.gif" and see the image... but it's not there.
So what comes next?
Note that the self signed (not paid for) certificate you have made (or seem to have made) will still show a pop up warning box in all browsers (untrusted issuer etc). You really need to get a paid cert (try a popular domain company advertising cheap certs, they are fine).
Issue #1:
SSL certificate is not for the right domain
After some tinkering and a restart by my hosting provider, the situation has changed.
I wanted an SSL certificate so I could show this image in a secure way:
https://www.example.com/images/logo.gif
instead, I can only get SSL love via this URL:
https://myhostingprovider.com/home/myaccount/public_html/examplecom/images/logo.gif
Yeah sure it works, it's HTTPS and I see the image, but that URL is obviously not acceptable for public consumption.
Problem arises because I'm hosting a whole pack of sites all on the same IP.
The ISP says I'll need to buy another IP address, so the SSL will work on URLs starting with "example.com".
Issue #2:
I'm still self-signed and my browser really hates that
From what I've learned in the past 6 hours, a certificate is only trustable if someone sells it to you. If you sign your own certificate, it's like making your own credit cards out of construction paper and puffy stickers. They're pretty much garbage.
My registrar is selling SSL certificates for $29.99/year. Does that sound like a good deal?
https://myhostingprovider.com/home/myaccount/public_html/examplecom/images/logo.gif<< If your files are available through this path, whether https or http... you need to get that blocked entirely by your ISP (or ditch the ISP). Talk about a duplicate content nightmare!
You are right. Self signed only works within a small trusted community, e.g. to verify the ID of your staging server, backup server or colleague's drop box.
Self signed only works within a small trusted community, e.g. to verify the ID of your staging server, backup server or colleague's drop box.
or company intranet, for example...
My registrar is selling SSL certificates for $29.99/year. Does that sound like a good deal?
IMO it is, and if it's the same registrar/host as I have, there should also be an area where you upload the cert files.
There are two "bits" to installing a cert for most servers: the cert itself (domainname.crt) and the cert bundle (bundle.crt or something.) You apply for the cert. The "Authority" check things out, then decides yes, this is a valid cert, and sends you the cert files.
They can be manually installed by an admin, OR in some hosting solutions (sounds like you have this) you can copy/paste or upload the two raw cert files and the control panel will install it for you, without a restart. Immediately after uploading the two files, you should be able to click the icon on the site and see the trusted authority, expiration date, etc.
SSL certificate is not for the right domain . . . Problem arises because I'm hosting a whole pack of sites all on the same IP. .... The ISP says I'll need to buy another IP address, so the SSL will work on URLs starting with "example.com".
Your cert is self-signed because you created an internal cert, the one you bought is just not properly installed and recognized by the cert authority. See the example above; you create a cert and it is bound to a specific domain name, company, and IP address - so yes, you need an IP dedicated specifically to this domain for the cert.
Note the importance of "a specific domain name" - you would need TWO certs for example.com and www.example.com. You won't be able to use this cert for all the domains unless you buy a "shared cert" for that purpose - far more expensive than $29.99/year.
I can only get SSL love via this URL:
[myhostingprovider.com...]The really important part here - when you do this, double click the icon, What do you get? I'm guessing something like "hosting-company" as the cert owner. Hence, this may be a goose chase; you're accessing this file via a secure certificate, but it's not your cert.
If you sign your own certificate, it's like making your own credit cards out of construction paper and puffy stickers. They're pretty much garbage.Yes and no. There are two main functions of a cert: to encrypt the data to and from the browser, and to verify the site and site owner by the cert authority (the issuer.) A self-signed cert will still encrypt data to and from the server, but where yours is failing is the second part, not being recognized by the cert authority. It's just not yet properly installed.
One last bit of info to simplify your life AFTER it gets installed properly:
https://www.example.com/images/logo.gifWhile this works, in most cases it will not be necessary. use
/images/logo.gif
Why? Because if you request the page via http, it will serve the non-secure version. If you request the page via https, it will serve the secure version. The exception is if you config your system to serve https ONLY from a specific location, like httpsdocs instead of just httpdocs. This will make your pages portable - once you hard code the domain name in the src= or href=, it's there.
Where people get jammed up is when they get "this page contains insecure items" they immediately change all their URL's and src's to https:..... and still get the warning. Usually this is generated by something you don't expect. Prime examples are the stock Analytics URL that is non https. There is an easy if statement in the JS provided by Google to request the secure urchin as opposed to the non-secure one. Don't just drop in the secure version on all pages, it will slow down non-https pages.
Another one that often blind sides you: the junk Flash code on publish from Flash with the "code base" or "download URL" pointing to the non-secure download URL at MM/Adobe. There is a secure URL for these as well.
For dynamic scripts, you do something like
$flash_url = //non secure url
$secure_flash_url = // secure url$url_in_page = ($ENV{'HTTPS'} == 'on')?$secure_flash_url:$flash_url;
(or use regexp for case insensitive, sorry for the PHP/perl mixture)
>>https://www.example.com/images/logo.gif
While this works, in most cases it will not be necessary.
I see. Alas, this is a case where my image (the site's branding) is being shown on the secure checkout page of a third-party financial site (a famous one, owned by eBay). In order for them to hotlink my image onto their page, they must use the full URL. And unless my image is served with SSL, the user gets that annoying message "not all things on this page are secure, blah blah blah".
That's why I want SSL to deliver an image. Otherwise I wouldn't care much about encrypting&certifying a GIF file.
Yes, I'll be using SSL in other parts of the site too, but in this situation a relative URL won't cut it.
I've just heard from my ISP - they've obtained a dedicated IP for my site. It'll take some finaggling to get it set up properly, but at least there's progress.
Hey - a side note, did you know that the same-domain policy in JavaScript applies to the protocol as well? If you're on a page hosted at http://example.com, you can NOT make an AJAX request to https://example.com/script.php. And vice versa. Now THERE is a situation where using a relative URL is actually crucial.
Just a handy tidbit that I found out the hard way.
So, I'm waiting to see what the next step is. I have the Certificate, and I have the IP, and I'm trying to figure out how to put all these pieces together. Right now I'm thankful that my hosting provider has a pretty decent support staff offering good service and good advice.
