Why is it so damned difficult to obtain an SSL certificate? I've been trying to renew the one for the company I work for (we've already been through the initial stuff once before, but I never personally had a hand in it) and quite frankly, it seems rather absurd that an SSL certificate provider would ask for, among other things, a Dun and Bradstreet business background check, three different contact names within the company, and apparently when we first obtained it, the Article of Incorporation for the business.

As far as I'm concerned, an SSL certificate is the same as any piece of software or program or component. Not only that, it's installed on a computer for the purposes of providing encryption and security. If anything, an SSL certificate should be easy to obtain because it has direct e-commerce applications. So why in the blue HELL does a company have to jump through so many hoops to get one? What's the logic behind it?

That is because the higher value SSL certs validate who you are. They are much more than simply encryption for your website's https links.

If all you are after is encryption, use a QuickSSL cert. You can get this immediately online, nothing needed other than you need to be the admin contact for your domain.

-t

Thank you. This does make some sense to me. Unfortunately I need the 128-bit SSL since the restriction our bank put on us is that any credit card transactions done online had to use the highest encryption possible (they were quite explicit on this too.)

The logic behind it is very sensible, dont you want the companies you give your credit card details to have been properly checked out. If it was easy to get SSL then it would defy the hole point in making sure the company you use has one.
I for sure want the companies I give my card details to to have gone through strict checks.
If the bank didnt give the guidlines for 128-bit SSL would you have gone for something less????

TheGAME1264, the QuickSSL certs that you can get immediately for $99 at www.geotrust.com are 128 bit so that should satisfy your bank.

Expanding on what Thewitt said, Geotrust doesn't go to great lengths to prove that you are who you say you are. Does that matter? I guess it depends but in most practical web applications I don't think it matters much at all since the average web visitor doesn't have a clue about checking the certificate details for authentication. It means that a visitor on your checkout page could click on the little padlock or key on their browser, look at the somewhat cryptic certificate details and think, "I wonder if this store is an imposter because he doesn't have a Verisign etc certificate?".

Of much greater concern is what you do with the credit card details after you receive them. I suspect in many cases with poorly written shopping carts etc, a hacker break-in at the server is a much more likely occurrence than someone intercepting the live data packets. Sure you should encrypt the data stream with SSL, but your bank should probably be more concerned about what happens next.

Cheers
Ross

The payment processing in itself isn't an issue, since the one we chose had to be preapproved by the bank before we were allowed to use them (a delay of about a week). And as it pertains to the SSL certificate itself, I don't really feel it's all that necessary to verify who we are via certificate since most of the people who use the application I developed (it's rather industry-specific) already know who we are. As you pointed out, Joe Blow off the street using his computer isn't going to know how to verify a company using an SSL. The problem is that the thing's already been ordered and to my knowledge paid for. Otherwise, since all I'm really after is the encryption itself.

Originally posted by TheGAME1264
Thank you. This does make some sense to me. Unfortunately I need the 128-bit SSL since the restriction our bank put on us is that any credit card transactions done online had to use the highest encryption possible (they were quite explicit on this too.)

As far as I am aware of the QuickSSL cert does support full 128bit encryption. What would make you think otherwise?

Hello
Although Thawte and Versign check your company documents its in their terms and conditions that they accept no responsibility of the company is not who it says it is.
So, bascally there is no difference betweenthat and Quick SSL who make no pretence of checking the documents.

Gordon

Originally posted by avara


As far as I am aware of the QuickSSL cert does support full 128bit encryption. What would make you think otherwise?

I was referring to an earlier statement made by jgriff64 asking if I'd go for something less. I haven't actually looked at the QuickSSL stuff yet, although I will this afternoon.

Geotrust have got it right..

QuickSSL or even the Equifax Business ID certs are simply SSL with different levels of ubiquity and they address the simple need to have data encrypted.. This is not intended to prove that the recipient of the data is trustworthy, just that the actual transfer is safe..

As far as providing some evidence that the company/person you are dealing with has some likelihood of being trustworthy, they provide True Site which is a verification service requiring documentation to support the identity of the site owners etc..

These are choices that site owners can now make, unlike with verisign/thawte who purport to bundle these quite separate issues together in order to squeeze more money out of people..

Microsoft etc do not explain that these issues are also inherent in their browser functionality and as far as I am concerned it';s just another way for these giants [Network Solutions, Verisign, Microsoft etc] to mislead their way into profit, ever so subtley..

The whole reason for having a Certificate Authority sign your digital certificates is because they are putting their good name on that certificate. For them to do that, they are going to verify that you are who you say you are. That's what you are paying them for, the verification process.

If the respectable CAs didn't do that, then anyone would be able to get a certificate signed by a respectable CA with your company name on it. Take for example the problems caused when Verisign signed a cert with Microsoft's name on it without verifying it first.

If you don't care about having a CA sign your certificate, generate and sign one yourself for however many bit encryption you want. And your users can ignore the message saying "This certificate wasn't signed by a respectable CA" or whatever it says.

A CA is what you are referring to.. a CSR is the request.. there is no CSA..

This is only something that refers to a browsers decision to show the pop up saying whether or not it is recognised.. current root certs or the portion of an SSL encryption cert which causes this to happen is not driven by angels of trust.. it's just a way of controlling the actions of people who don't know any better..

The issue is the differential between 'encryption' of data and the 'trust' in the web site you are exchanging data with.. so in one respect you are correct, you can create a cert yourself and have the pop in the browser, but then everybody is programmed to believe that means it's a shonky deal.. what crap..!

If the public understood that there was a difference, and the dreaded pop up wasn't displayed using such spurious wording which instills fear and loathing, then it would be a fairer and less oppressive system.. not to mention cheaper..

Ever heard of a man-in-the-middle attack?

That's why reputable certificate authorities verify your identity.

It is a simple matter to get hold of a Verisign or Thawte certificate with false information.. to mix this 'verification' up with the transfer of encrypted data and charge an arm and a leg for it serves no purpose other than to fill Verisign's coffers.. and to mislead the public..


I am a strong advocate of proper verification systems for web sites who are taking money from the public, and would promote a much stricter method if I had the means... but the Verisign $300 SSL cert is no different from the Network Solutions $30 domain name.. it takes advantage of people who have no experience but will believe what their PC tells them..

Who decides what a reputable authority is.. ? Microsoft?

These are two quite separate issues and should be dealt with that way.. ID to open a bank account is a great example.. it generally stops people from receiving cheques/payments under false pretences, and if they do, they can be tracked..

Not all SSL certs are used to cover financial transactions..

Originally posted by cperciva
Ever heard of a man-in-the-middle attack?

That's why reputable certificate authorities verify your identity.

I haven't. What is it?

And there are much easier ways to verify a company's identity. Why not just look up the name of the company asking for the certificate and match it with whatever records are on file in the country/state/province it does business in? It's been like two weeks now and still nothing.

Now I've got people from Dun and Bradstreet calling me. What the hell does this accomplish? And when it comes right down to it, does having an SSL necessarily establish ethical business practices on behalf of a company? No, it does not. After all, many web hosts who host spammers, pornography, pyramid scams and God knows what else can get SSL certificates. So as felix220 points out, it's nothing more than a cash grab. If the "order" hadn't already been paid for, I'd have used Geotrust. And I probably will next year. While there is a certain logic to verifying the identity of a company when doing business with them using credit cards and an SSL, it's not completely necessary.

Originally posted by TheGAME1264
I haven't. What is it?

Let's suppose that you have lots of credit card numbers coming into your website via https. Let's further suppose that I'm an evil person who wants to steal all those credit card numbers.

Here's what I do:
1. I get a certificate authority to issue me a certificate with your name attached. Assuming I can find a "certificate authority" which is willing to issue me a certificate without verifying my identity, this is easily done.
2. I start broadcasting routes claiming your IP address. Not trivial, but not excessively difficult.
3. When packets arrive on any port other than TCP/443, I just forward them towards their correct destination.
4. When packets arrive on TCP/443, I respond with my (fake) SSL certificate, and open an entirely new connection to your server.
5. When further packets arrive on TCP/443 -- encrypted with *my* key -- I decrypt them, write the packet contents to disk, and then re-encrypt them and send them on to you. When you send a response back, I reverse the process.

(of course if I want to be even more evil I could tamper with the data before forwarding it).

The reality is however that "man in the middle" schemes are very difficult to do, and very rare in practice.

You are at significantly higher risk at having your credit card information exposed by someone storing it on a shared server with the database username and password in a text file, than you are having someone mount a successful man in the middle attack.

The real travesty here is that encrypted data connections were ever tied to entity validation in the first place.

We sell an equal number of low-end "immediate" certs and high end company validation certs. There are many people who can take advantage of either, and some that can benefit from the higher level, company validation.

Quite frankly, if you can perform a man in the middle attack, you can do so with any valid cert that the browser recognizes. You don't even have to impersonate my website to pull that off.

-t

Originally posted by thewitt
Quite frankly, if you can perform a man in the middle attack, you can do so with any valid cert that the browser recognizes. You don't even have to impersonate my website to pull that off.


Except that most web browsers will put up a warning that "this site has a valid SSL certificate, but it does not match the site name".

I agree with another poster that this SSL business is merely 'a cash grab' for big companies. It should not be Verisign/Thawte job to verify our identity. The authority should be able to do that job better and more efficiently.

Actually there is a mechanism in SSL that allows this, it is called 'certificate chaining'. And why the browsers maker do not implement this feature is beyond me, and I wouldn't even get into the possibility of conspiracy theory between the browser makers and certificate authority.

Right now the path of trust is like this:

1. end users trust the o/s vendor or browser vendor
2. o/s or browser vendor trust the certificate authority (verisign, thawte, etc), and install their certificate on the browsers by default
3. those CA verify our identity and grants a certificate, saying that they trusts us.

Then, end users and web site owner can do business securely.

With certificate chaining, there could be more step of trust involved. For example.

1,2. same with above
3. CA grants a certificate to a local authority, in most cases that would be local government agency that authorizes company incorporation.
4. that local goventment agency grants a company with an SSL certificate.

Or, even better: :D
1,2. same with above
3. CA grants a certificate to a web hosting company
4. that web hosting company grants an SSL certificate to each of its customer

Originally posted by priyadi
It should not be Verisign/Thawte job to verify our identity. The authority should be able to do that job better and more efficiently.
I agree that we shouldn't have to rely on VeriSign, but users will still have to rely on some sort of indepent, third-party verification system in order to verify the identity of the certificate holder.

I think the best solution would be to get more certificate issuers in the business, making VeriSign have to compete for its market share. This won't happen until business warms up to the internet again and competent concerns get in the game. But there's no reason why a well-respected institution such as Charles Schwab or Morgan Stanley can't start issuing certificates to its trusted clients. For less money. And with better customer service.

Just a side note: If anyone thinks having the government assume a role in the process will somehow remedy the inefficiency of the current system, PM me. I have some real estate I'd like to sell you. Over the internet. With an untrusted SSL certificate.

Originally posted by bigmattyh
Just a side note: If anyone thinks having the government assume a role in the process will somehow remedy the inefficiency of the current system, PM me.

Actually, I think that the government could do this more efficiently. Why? Because the government already issues birth certificates, passports, citizenship documents, etc... they already have the infrastructure in place to verify peoples' identities.

Originally posted by cperciva
Actually, I think that the government could do this more efficiently. Why? Because the government already issues birth certificates, passports, citizenship documents, etc... they already have the infrastructure in place to verify peoples' identities.

Well, I don't know about your standards, but if you made people wait six weeks to get their SSL certificate -- the same length of time that it takes to get a passport -- most people would call that inefficient.

And what's worse: there'd be nowhere else to go. Last I looked, bureaucrats have 0 incentive for doing their job with customer service in mind.

Originally posted by thewitt
You are at significantly higher risk at having your credit card information exposed by someone storing it on a shared server with the database username and password in a text file, than you are having someone mount a successful man in the middle attack.

Sad enough.

Originally posted by bigmattyh


Well, I don't know about your standards, but if you made people wait six weeks to get their SSL certificate -- the same length of time that it takes to get a passport -- most people would call that inefficient.

And what's worse: there'd be nowhere else to go. Last I looked, bureaucrats have 0 incentive for doing their job with customer service in mind.

That's also assuming you're in a country that can even provide that kind of service. What if you were trying to set it up in a country where the government was in a state of flux? (Hey, it's possible.) Not only that, if any government got into it, it'd be taxed to Hell and back again.

Originally posted by TheGAME1264
And there are much easier ways to verify a company's identity. Why not just look up the name of the company asking for the certificate and match it with whatever records are on file in the country/state/province it does business in? It's been like two weeks now and still nothing.

Now I've got people from Dun and Bradstreet calling me. What the hell does this accomplish? And when it comes right down to it, does having an SSL necessarily establish ethical business practices on behalf of a company? No, it does not. After all, many web hosts who host spammers, pornography, pyramid scams and God knows what else can get SSL certificates. So as felix220 points out, it's nothing more than a cash grab. If the "order" hadn't already been paid for, I'd have used Geotrust. And I probably will next year. While there is a certain logic to verifying the identity of a company when doing business with them using credit cards and an SSL, it's not completely necessary.

Getting a certificate signed by a CA isn't supposed to guarantee that your organization is reputable, only that the certificate was issued to your organization. You really should read up on digital certificates to see what they are used for and how signing them allows for a type of identity.

Like I said before, if you just want to encrypt your traffic, use a self signed certificate.

I have to agree with felix220, that perhaps browsers should just have two different kinds of locks. One for digital ID, and one for digital encryption.

Originally posted by felix220
A CA is what you are referring to.. a CSR is the request.. there is no CSA..

You're right, I was referring to a CA. There are certificate signing authorities, although they are commonly referred to as Certificate Authorities. Sometimes I forget this myself, as they logically should be commonly referred to as Certificate Signing Authorities. After all they aren't authorities on certificates, but they are authorities who sign them.

What do you think?

"Certificate Authority" is a bastardized form of "Certification Authority". The intended role of a CA is not merely to sign certificates; the role is to *certify* that the name on the certificate matches the person/organization asking for it to be signed.

Originally posted by bigmattyh

I agree that we shouldn't have to rely on VeriSign, but users will still have to rely on some sort of indepent, third-party verification system in order to verify the identity of the certificate holder.

I think the best solution would be to get more certificate issuers in the business, making VeriSign have to compete for its market share. This won't happen until business warms up to the internet again and competent concerns get in the game. But there's no reason why a well-respected institution such as Charles Schwab or Morgan Stanley can't start issuing certificates to its trusted clients. For less money. And with better customer service.


Yes, I agree, there should be another verification system. It should be tied to local authority to ensure better verification. It doesn't have to be government agency though, it was merely an example in my previous post. With current system it is too hard for verisign to verify business around the world, hence the expensive price. For example, how could verisign verify my company identity? A person could have faked the letters to make it looks like a valid organization, and verisign wouldn't know it.

But I don't think getting more CA in our browser will solve the problem. This will lead to more bloat to our browser. A better solution would be end users signing to a second or third level CA. Just like the domain name system right now, we don't register directly into root DNS, but on the top level domain (com/net/org) or second level domain (co.uk). Thay way, the system could be more decentralized, unlike today's system.

Originally posted by TheGAME1264


That's also assuming you're in a country that can even provide that kind of service. What if you were trying to set it up in a country where the government was in a state of flux? (Hey, it's possible.) Not only that, if any government got into it, it'd be taxed to Hell and back again.

The solution is easy. If the local authority is unable to identify him, he could go with Verisign/Thawte instead, just like today. Or his web hosting company could grant a certificate for him.

The organization that issue certificate does not have to be strictly a goverment entity (that's only my example). It could be a third party organization that have access to information the government have.