Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Digital Certificates: place your order

By imrdkl in Technology
Sat Jun 08, 2002 at 10:12:05 AM EST
Tags: Focus On... (all tags)
Focus On...

Sometime soon, or in the near future, you may need to get a digital certificate of your own. There may be several reasons for this requirement - you might be looking for secure access to your bank account or other services, or perhaps your employer is setting up a Public Key Infrastructure (PKI), and you must "join up" to have continued access at your job. If you are a developer or systems administrator, you may need to obtain a certificate for authenticating a server, or binary code which is part of your web application. Alternatively, you might just be curious about what certificates are, and decide to obtain a certificate of your own to investigate.

In this article, the second of a three-part introduction to digital certificates, we'll take a look at the process of obtaining a certificate, from key-creation to installation. In the previous article, I discussed what digital certificates are, and what they're used for. I'll again limit the focus of this article to obtaining certificates which are used in a Web-based PKI, including Client, Server, and CodeSigning certificates. Particular attention will be paid to client certificates, since those who need or want to obtain one may be the least technically-savvy. Each of these types of certificates was introduced in the previous article, and I'll assume that the reader is somewhat familiar with what they are.

There are essentially four primary steps in the process of obtaining a digital certificate, three of which must be performed by the person or entity which wants to obtain the certificate, also called the Subject, and one which must be performed by the Certifying Authority (CA) which issues the certificate, also called the Issuer. You may recall from the previous article, that I also referred to the Subject as the Grantee of authority, with the Issuer as the Grantor. Regardless which term you use to define the roles, the interaction between the them is the same.

If you are ordering a certificate through your web browser, then this entire process may appear to be a single seamless transaction, but it's worth the time to consider the steps individually before you make your request.

The Four Steps to Obtaining a Digital Certificate

  • Create the Key Pair

    The first step in obtaining a certificate is to create the key pair which will be used in it. This keypair may already exist, for example if you already have a key pair which you use for other purposes. Alternatively, if the certificate is to be issued for installation on a device such as a SIM Card, ID card, or a Mobile telephone, the key pair may already be installed, and the Subject will have access to the password (PIN) which safeguards the existing private key.

    As mentioned before, if you are going to use a certificate for which you did not generate the keys yourself, then you should consider who has created the keys, and perhaps find out if any copies were made. When possible, always create your own key pair.

    In any case, the key pair will be created via some means. This is the first step in the process of obtaining a certificate.

    Client certificates, such as those which are installed in a web browser for secure access and single sign-on, may have their key pair created via communication between the browser and some external software, or possibly within the browser itself, via built-in key-generation capabilities. For Server certificates, the key pair will typically be created by the server administrator or operator of the server, via software which is external to the server software, such as openssl. Keys which are to be found within Codesigning certificates are also created via external software, or alternatively via tools included with the software development package which is being used to create the application for signing.

    A key pair can be generated using a large number of algorithms, also called "Providers" in MSIE. The two most common types of key algorithms are named RSA, and DSA, but there are others. When creating a key pair via the Microsoft IE browser, a list will be presented with all of the available providers installed on the Subject's machine, and which are acceptable to the Issuer. If you don't know the differences well enough to choose, then have a look at this list which defines them, including things like key lengths, and other relevant details.

    After the key pair is created, you're ready to create the actual request for a certificate.

  • Creating a Certificate Request

    The next step which is taken, in the process of obtaining a digital certificate, is to create something called the certificate request, (or certreq). The certreq takes the public key of the requestor (Subject) and builds it into a file-container which is to be opened, read, approved and signed by the CA. Besides the public key, the certreq contains the Distinguished Name (or DN) of the Subject along with some other information.

    The DN is an important part of the certreq, and eventually, the certificate. A DN is a long text string built up of individual components. The components are typically based on a specific protocol for heirarchical information storage and identification, called Lightweight Directory Access Protocol. LDAP, and it's heavier (and proprietary) counterpart, X.500. These protocols define an extensive list of identifiers, but the certificate DN typically includes only a small subset of them. Things like Name, Location and Email Address which pertain to the certificate-requestor, as well as some of the requestors organization details, such as Organization Name, and department, may be requested by the Issuer to validate the certificate, and construct the DN.

    The interface for obtaining these bits of information may be web-based, or via a command-line. In either case, the Subject will be asked questions about themselves or their organization, and will input the answers. Other details about the Subject may also be requested at the time the certificate is ordered which will not be directly embedded in the certificate, as the DN is. These details will be read, validated, and permanently stored by the Issuer as part of the overall certificate-ordering process.

    After the certificate request is built, it is then sent to the Issuer. Email may be used for this, or it may be a seamless part of the web-based certificate request.

  • Certification Authority approves and signs the certificate

    After the certreq is sent to the CA, a number of steps are taken in the process of approving the certificate. I won't discuss these steps in depth, except to say that they may vary with any given Issuer. These steps are the validation of the request. They typically conclude with the signing of the certificate request, and the creation of the actual certificate. When the certificate request is signed, the Issuer inserts its own DN into the certifcate, and inserts the Subject's DN from the certreq, along with its public key. A lot of other information is placed into the certificate by the Issuer, which I'll discuss in the next article.

    After the certificate is created, a notification is typically sent to the Subject informing them that their certificate is ready, and where they may pick it up. Sometimes, the certificate may be sent via email as well. This sometimes concerns people, that their certificate has been sent via email, but it's important to keep in mind that a certificate can't be used for access without it's private key, which the CA has usually never seen, and would never send. The certificate contains only the public key.

    Depending on the intended usage, type, and "strength" of the certificate which is desired, the approval process may be short and simple, or quite lengthy, requiring extensive documentation and legitimation, especially if the certificate is being requested for a business. Certificates typically also require the payment of a fee to the CA, a sort of insurance premium, for them to certify the requestor, and guarantee their identity.

  • The certificate is installed by the requestor

    After the notification is received, the certificate is finally installed on to the device or machine for which it is intended, and can then be used in the process of secure communications. If a server certificate was requested, the web server is typically restarted to activate the certificate, while client certificates may be used immedietly to login. CodeSigning certificates are installed within the developer's private files, so that he may then use the certificate to sign code which will be deployed as part of a web application, downloaded, and run on a client machine.

So, we've finally got a certificate. That may be all that the average user ever cares about, once it's installed. Some, however, may wish to examine the the certificate a bit more closely, to get an understanding about how it was made, and what the Issuer has built into it. As we've seen, a digital certificate probably won't be hung on a wall, but it bears closer inspection. What did the money that you (may have) paid, and the identification you provided, get for you, anyways? In the next article, we'll take a much closer look at digital certificates, how they're built, and what they mean, to find out.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Preferred Cryptographic Provider
o RSA 25%
o DSA 9%
o AES/Rijndael 40%
o Other 25%

Votes: 32
Results | Other Polls

Related Links
o previous article
o key pair
o openssl
o this list which defines them
o Lightweigh t Directory Access Protocol
o Also by imrdkl

Display: Sort:
Digital Certificates: place your order | 50 comments (42 topical, 8 editorial, 0 hidden)
Hehe (4.25 / 4) (#7)
by trhurler on Fri Jun 07, 2002 at 05:58:54 PM EST

The use of what amounts to a bearer bond whose value is identification on systems whose software includes new holes discovered daily is truly hilarious. Yes, these are hard to forge - but the end result is a string of characters that, if compromised, render the whole scheme useless, or worse still inspire false confidence.

PKI is such a great scam...

'God dammit, your posts make me hard.' --LilDebbie

Please expound (4.00 / 1) (#8)
by imrdkl on Fri Jun 07, 2002 at 06:19:03 PM EST

Is there nothing that be kept a secret anymore, or is it just the current algorithms that are flawed? I recall you asking about a rather special secure transport configuration in a recent diary, so you must trust something about encryption and the various algs that do exist. So, where are the holes? The DN means nothing unless you trust the issuer. Look in your browser's root store, and tell me how many rootcerts you have there, staring back at you. You already trust those, don't you?

[ Parent ]
That's just it (4.75 / 4) (#9)
by trhurler on Fri Jun 07, 2002 at 06:37:03 PM EST

Remember, certs are hard to generate(you need the keypair, and there is some social engineering involved,) but dead easy to copy, if you can get access to them somehow. For instance, I find a hole in your system(these are plentiful in most systems, though it may take some effort,) get into your machine, get root(easy once you have a shell,) and proceed to dig around in /dev/kmem for your certs(since the disk copies are probably encrypted with a passphrase.) Once I have them, I can go, set them up as my own, and pretend to be you, and while the cert will still provide privacy for your users, it no longer uniquely identifies your server as being you.

Insecure platforms cannot be secured by bolting on encryption, even if it IS good encryption, which is the big lie being perpetrated by PKI vendors.

Me, I'm not worried about identity - just privacy. So yes, certs work well for me.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Some fair points (5.00 / 1) (#10)
by imrdkl on Fri Jun 07, 2002 at 06:47:43 PM EST

but not really relevant to client certificates. Server certs can, theoretically be comprimised by coring the process, or examining a device with sufficient skill, it's true. However, keep in mind that obtaining a dedicated server certificate still does not imply the ability to manipulate the DNS to become the man in the middle. SSL will disappoint you more quickly as a secure transport, than X.509 will disappoint you as the enabling mechanism.

In any case, my point was that server certs and client certs are two different animals. One typically identifies a business behind a webserver, whereas the other identifies the customer, employee, or other business partner. The motivation for acting in the role of the business, which would require a server certificate , perhaps obtained by the technique you describe, is not the same as for spoofing a customer. Not the same role, not the same platform or full-time processes with the keys open, and not the same type of entity.

[ Parent ]

Hmm... (5.00 / 1) (#11)
by trhurler on Fri Jun 07, 2002 at 07:02:14 PM EST

First of all, manipulating DNS is not significantly harder than stealing certs off a server; both are done in much the same way, actually.

Second, client certs. Frankly, given the "security" of your average client machine, and given that your average user will undoubtedly use his girlfriend's cat's name as his passphrase if he even uses one at all, these are about as useful in establishing identity as me putting "-- \ntrhurler" at the end of an email. Furthermore, web browsers keep your credentials until closed, and how many people bother to close their web browsers these days? (In case you want to argue about bad use vs bad technology, if the technology is constructed in a way that ensures that people will misuse it, then yes, that is a technological problem.)

Really, spoofing a customer is every bit as useful as spoofing a business. More useful in some ways, as you are less likely to get caught, and a good credit history is worth a lot of money to an identity thief.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Er (none / 0) (#13)
by imrdkl on Fri Jun 07, 2002 at 07:17:25 PM EST

Where are you trying to lead this, exactly? First you pooh pooh PKI, then you acknowledge you use certificates yourself. Is not identity more likely to be trust-able if people understand the technology? PKI is here to stay, as your own usage testifies. Perhaps usage should be limited only to those who are smart enough to know that it really doesn't work?

[ Parent ]
Ah (none / 0) (#14)
by trhurler on Fri Jun 07, 2002 at 07:30:50 PM EST

You see, I use it for what it does right. My point is that most people use it for things it doesn't really do at all on any real operating system and with any real server software. They imagine that the emperor wears clothes, so to speak.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Methinks you should upgrade (none / 0) (#16)
by imrdkl on Fri Jun 07, 2002 at 07:43:53 PM EST

One time pads and a transport that wears a trenchcoat, and a fedora pulled down low over his eyes.

[ Parent ]
I tried that (5.00 / 1) (#19)
by trhurler on Fri Jun 07, 2002 at 07:58:24 PM EST

Sadly, you just can't trust those bastards. So, I had to buy my own trenchcoat and my own fedora, but really you have no idea how stupid most people look wearing a fedora. After that, I decided maybe textual steganography would work, and the name "trhurler" came to me in a vision...

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Seriously (none / 0) (#24)
by imrdkl on Fri Jun 07, 2002 at 08:19:18 PM EST

I detect a whiff of distaste from you, regarding DigId in general. Remember that PKI, for now, only identifies devices, which purport to be held and operated by people. Whether the device is a secure Id card, computer, mobile phone, or what have you. I think it's important that people understand PKI and X.509, from your perspective as well, before they willingly participate and utilize the technology.

I do prefer certs to cookies and BasicAuth, but I prefer a handshake and cash best of all.

[ Parent ]

Well, (none / 0) (#27)
by trhurler on Fri Jun 07, 2002 at 08:28:12 PM EST

We agree on one point: people need to understand these things they're putting their faith in. The point we disagree on is that if people really understood them, I think they would hesitate to use them at all for most financial purposes.

In particular, most people have no idea how easy it is to steal these things, no notion that they don't know who's at the keyboard, and no clue why either of those things might matter. If you told them "the cert can be stolen," they'd assume that was bad because of the presence of the word "stolen," but they wouldn't have any real idea why.

The executives who buy these systems, most of the techs who operate them, the people who rely on them - none of these people usually understand the technology in any real depth. The techies might have read applied crypto, but if so, that will just have given them an even more inflated sense of the worth of crypto in securing modern systems than everyone else has, and the vendors, who ought to know better, are selling this stuff up like it is the answer to all of life's problems, because shareholders are all they care about.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
If you really think that (none / 0) (#28)
by imrdkl on Fri Jun 07, 2002 at 08:48:43 PM EST

then you'd better put a big sign around your neck and walk the streets in front of the pentagon. The DOD is making big strides in PKI, as well as the health-insurance and financial industries. (I plan an article on that later) Granted, it costs alot, if there's good structure and validation behind it, but the implementation of much of the government PKI pilots is based on openssl, believe it or not.

[ Parent ]
Cryptographic dangers (none / 0) (#44)
by Trepalium on Sat Jun 08, 2002 at 07:21:55 PM EST

Yes, private keys can be stolen, systems compromised, and so on. However, the danger isn't limited to internetworked machines, or even computers. Take purchasing something, for example.

Most online merchants are very careful with your credit card details, and limit the number of places where your full credit card details are reproduced to. Contrast this to even a conventional store, where your sales reciept will likely show your credit card number, the card will likely not be hidden to prevent the other people around you from seeing the number/expiration, and so on. It's even likely that your credit card number will be attached to your order the entire time the order is bring processed, available to any employee that may want to snatch it.

There's devices out there that people hook onto the bank card machines at stores that will record your bank account card number and PIN, and aren't much bigger than a ping pong ball. The only reasonably secure form of payment is cash, and that limits your options (and you can always be mugged and have your cash taken away from you). There's risks in anything, many of which, cannot be mitigated.

[ Parent ]

Server keys, not server certs (none / 0) (#21)
by gbroiles on Fri Jun 07, 2002 at 08:08:10 PM EST

Don't you mean to say that server private keys can be compromised with suffcient skill? Server certs are presumably available to anyone, and possession of a cert alone means nothing - it's possession of the private key which matches the cert that's interesting.

[ Parent ]
Yes indeed (none / 0) (#23)
by imrdkl on Fri Jun 07, 2002 at 08:14:09 PM EST

SSL (be it server-only SSL or 2-way SSL where both sides have a certificate) requires that the server sends it's cert, with the builtin public key to every client. No secrets there. I was going to point this out to the gentleman in the fedora, but dismissed it as irrelevant. I think we assume that all know that the private key is the interesting bit, for any given certificate, regardless whether it's server or client. I also alluded to this in the article.

[ Parent ]
Finding keys (4.00 / 1) (#43)
by dennis on Sat Jun 08, 2002 at 06:34:02 PM EST

Here's a paper (pdf) that describes how to efficiently find secret keys hidden in gigabytes of data.

While we're at it, here's Bruce Schneier's Ten Risks of PKI. One tidbit:

One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don't own a secure computing system with physical access controls, TEMPEST shielding, "air wall" network security, and other protections; you store your private key on a conventional computer. There, it's subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it's protected by a password, how hard is it to guess that password? If your key is stored on a smart card, how attack-resistant is the card? [Most are very weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn't intend to sign?

This matters mostly because of the term "non-repudiation." Like "trusted," this term is taken from the literature of academic cryptography. There it means something very specific: that the digital-signature algorithm is not breakable, so a third party cannot forge your signature. PKI vendors have latched onto the term and used it in a legal sense, lobbying for laws to the effect that if someone uses your private signing key, then you are not allowed to repudiate the signature.

[ Parent ]
Bad idea. (4.25 / 4) (#12)
by tftp on Fri Jun 07, 2002 at 07:03:16 PM EST

Certification Authority approves and signs the certificate

This is not needed, unless you provide SSL services to everyone. You can be your own CA, with even much better security, and for free as well.

Poll: Preferred Cryptographic Provider

There is no such thing. There are crypto algorithms (ciphers), and what you listed are them. In any case, there is little in common between three listed. RSA is a generic public key cipher. DSS means "digital signature standard", and AES is a symmetrical block cipher. Neither of them can be preferred, they all do different things!

Oh, BTW, -1.

Yes, well (5.00 / 1) (#15)
by imrdkl on Fri Jun 07, 2002 at 07:33:08 PM EST

Thanks for the feedback, I guess.

A minor nit with your comment is that the certreq must always be signed, regardless of who operates the CA. For you to say that signing is "not needed" simply demonstrates your lack of understanding of how X.509 certificates are created. Additionally, keys can be created using DSA, RSA, and AES, and these key algorithms (and not their corresponding ciphers) all produce keys which can be embedded in an certificate. (Actually, I'm not exactly certain if the AES uses a distinct keyalg, but that's beside the point).

My poll does appear to have DSS, instead of DSA, which I do regret, but AES-Rijndael is one of the listed providers in the MSIE link I gave above.

[ Parent ]

More feedback (4.50 / 4) (#29)
by tftp on Fri Jun 07, 2002 at 09:23:39 PM EST

Thanks for the feedback, I guess.

I would have commented earlier, while your article was in edit queue (if it was there). But I was busy :-(

For you to say that signing is "not needed" simply demonstrates your lack of understanding of how X.509 certificates are created.

I never claimed that signing is not needed. I was referring to an external CA - that part is not needed; you can be your own CA, sign your own certificates, and publish your CA certificates for your customers to import. I know how it works, at least because I use it this way ;-)

Additionally, keys can be created...

What keys? Session keys? They are random. They'd better be ;-) Public/private keys? AES doesn't know what it is... I am confused.

using DSA,

No. You probably think "Diffie-Hellman / ElGamal" here. DSA/DSS is an algorithm for creating and verifying signatures (hashes of a text).

RSA, and AES, and these key algorithms

Neither RSA nor AES (nor DH to that matter) are "key algorithms" (a keypair generation, I guess?). They are crypto algorithms (a.k.a. ciphers), they take plaintext, combine it with a key and the result is ciphertext. Those are the terms. The key is usually a random number (or data block) for symmetrical ciphers (AES), or a carefully constructed piece of prime number puzzle (RSA).

AES-Rijndael is one of the listed providers in the MSIE link I gave above.

Win32 CryptoAPI is a bunch of marketspeak, and would be the last place on Earth I would be deriving my terminology from. There are plenty of good crypto resources on the Web, written by A-grade mathematicians; there is no need to look at Win32, crippled as it is with export controls.

AES and RSA are both ciphers, but it does not mean that one can be "preferred" to another, their areas of use don't even intersect! What would you prefer, a hammer or a screwdriver? AES is a block cipher, one of many (DES, Triple-DES, Blowfish, IDEA etc. etc.) and it does not mix with public key systems such as DH or RSA. Those are different areas of mathematics even. If anything, RSA serves only as a key delivery method for fast block ciphers to do the actual work.

[ Parent ]

You have gone through a lot of trouble (none / 0) (#32)
by imrdkl on Sat Jun 08, 2002 at 04:45:21 AM EST

to point out a flaw in my poll. While I do appreciate that, I should make it clear that I too have implemented a rather large scale CA with little or no cost. Generating the public/private keys for the certificates is possible in openssl(1) using one of either genrsa() which generates RSA keys, or gendsa(), which generates DSA keypairs, according to the openssl() manual.

I suspect that you're pretty new at this, and never had to use a DSA-based certificate, although your pedantics are mostly correct. However, when I said Provider in my poll, I was referring to the grouping of keyalgs and ciphers which are together under the MS definition, and via openssl(), which are the only links I provide.

So, while you're clearly well-read in the topic, I suspect you're having some difficulty seeing the forest, for the trees. I suggest that you relax your sphincter a bit, regarding this topic. Perhaps consider sharing about how you've successfully delivered a working CA.

[ Parent ]

DSA (1.00 / 1) (#48)
by thufir on Tue Jun 11, 2002 at 02:40:31 AM EST

DSA does use a private/public key pair, but the keys are used only for signing and verifying.

DSA/DSS is an authentication algorithm only.

[ Parent ]

I guess (none / 0) (#49)
by imrdkl on Tue Jun 11, 2002 at 08:01:48 AM EST

signing and verifying is the heart of X.509 and digital certificates.

[ Parent ]
Does anyone else have a problem with this? ;) (4.00 / 2) (#17)
by Jel on Fri Jun 07, 2002 at 07:43:57 PM EST

Seriously... the whole "Certificate Authority" thing bothers me.  Why not have an open, free system, like we've managed for most other important computing activities?  Surely digital security/identity deserves the same effort?

I think you're jumping to conclusions (4.00 / 1) (#18)
by imrdkl on Fri Jun 07, 2002 at 07:48:53 PM EST

An CA may be operated at any level, and by anyone. The point is not who operates the CA, but whether you trust it.

[ Parent ]
Oh yes, I know.. but... (5.00 / 1) (#20)
by Jel on Fri Jun 07, 2002 at 08:03:45 PM EST

The problem is that browsers will bitch at users about it.  Essentially, it all boils down to paying to have a stamp of approval put on your online communications.  If big corporations can be trusted, then why not open source communities?

[ Parent ]
Because... (3.00 / 1) (#22)
by ragabr on Fri Jun 07, 2002 at 08:09:22 PM EST

Big Corporations make most of their money off of their names, so it is in their interest to keep themselves trusted. Open Source communities don't have to worry about anything near as risky, since all they can lose is their users. Members of the community might be willing to accept that authority, but businesses are not, since there's no one to really take on the culpability.

And my tongue would be made of chocolate. Mmmmm. Chocolate.
[ Parent ]
Not true -- at least, not as I understand it. (5.00 / 1) (#26)
by Jel on Fri Jun 07, 2002 at 08:27:44 PM EST

Take Debian (the "serious" Linux distro) -- it's entirely open - as I understand it, there are trusted release packagers who produce the security updates etc, and everyone trusts their keys because Debian itself supports a fairly straightforward way of checking them.  Now, release packages come and go, but this system works, and doesn't require transfer of funds or any special form of authoritarianism.

Granted, there are a few difficulties creating such a system on a larger scale, but the internet community has achieved lots of big goals, often because it's the Right Thing(tm).  I don't see why this should be any different.

On the net, anyone should be able to hold a trusted, private, interaction without relying on the approval of any individual organisations or persons.

[ Parent ]

Again... (none / 0) (#31)
by ragabr on Sat Jun 08, 2002 at 03:20:12 AM EST

it's only the users of the community that are affected there. It's not financial data, which is the area where the corporations are providing their keys. There's a difference in the markets, and what you're talking about doesn't really matter one way or another, just have people start signing keys.

It's the business side that really matters, and no one is going to trust an Open Source solution, if only because they don't have the funds. It takes big money to set up a real venture like that, so the only way you're going to get a "neutral" organization is if the big organizations get together and provide one. But it's definitely going to require corporate backing, and I just don't see it happening, if only for lack of demand.

And my tongue would be made of chocolate. Mmmmm. Chocolate.
[ Parent ]
Keys? (none / 0) (#33)
by Jel on Sat Jun 08, 2002 at 06:07:52 AM EST

Maybe I don't know enough of what I'm talking about here, but I'm discussing certificates, not keypairs.

[ Parent ]
Sorry for the confusion... (none / 0) (#47)
by ragabr on Mon Jun 10, 2002 at 11:42:24 AM EST

I use certificates and keys interchangably and modify keys with "private" and "public" if I'm talking about key-pair crypto. But the context seemed to be clear in my post anyway.

And my tongue would be made of chocolate. Mmmmm. Chocolate.
[ Parent ]
There is nothing wrong or inappropriate (5.00 / 1) (#25)
by imrdkl on Fri Jun 07, 2002 at 08:26:07 PM EST

about the open source community making it's own CA. In fact, I've proposed this before in other forums. Running a CA takes time and skill, which are abundant in the open source community. However, a CA also requires persistence, pragmatism, and a verifiable sense of reliability.

[ Parent ]
Browsers and independent CAs (4.75 / 4) (#30)
by tftp on Fri Jun 07, 2002 at 09:42:52 PM EST

The problem is that browsers will bitch at users about it.

Point your clients to a link on your site: http://www.myfoosite.com/mycacert.crt and the problem is solved. The user needs to click couple of buttons, accept the new certificate forever, and the browser will now be using your CA certificate.

Essentially, it all boils down to paying to have a stamp of approval put on your online communications.

I doubt that CIA and FBI and NSA humbly submit their certificates for signing by VeriSign. Their certificates (or public keys) bear more trust than all Verisign certificates combined. Their certificates are not distributed publicly. Their certificates carry only the information the user needs to know. That's how it should be.

VeriSign is a convenient tool for low-key companies, Internet merchants, webmail sites, Microsoft etc. Everyone else (who cares about security) mints their own keys and certificates, and distributes them to people who need them. This gives companies much more freedom. For example, my company's secure Web site is designed only for customers; customers receive all the necessary keys, passwords and instructions and then can access the Web site. There is no place for VeriSign in this arrangement, and no need either.

[ Parent ]

ahh, OK ;) (none / 0) (#34)
by Jel on Sat Jun 08, 2002 at 06:10:23 AM EST

That was informative, thanks ;)

[ Parent ]
Unless I'm misunderstanding something... (4.66 / 3) (#36)
by John Thompson on Sat Jun 08, 2002 at 09:37:48 AM EST

The only reason to pay a third-party certificate authority is when the parties involved have no prior trust relationship, as in e-commerce and such.  If an employer wanted to use digital certificates to allow employees to use their services remotely, surely a prior trust relationship exists (your employer knows who you are, and you know who your employer is).  Wouldn't it then make sense for the employer to issue their own certificates (eg, using OpenCA) to employees and cut out the middle man and fees?

Please correct me if I'm missing something.

I agree (none / 0) (#38)
by imrdkl on Sat Jun 08, 2002 at 03:22:36 PM EST

employees, agents, suppliers, etc. typically all have a contractual relationship with a given company. Customers as well, are often considered "trusted", after credit validation and especially timely payments.

A business may certainly decide to take and distribute authority via X.509, based on existing relationships and histories. There are several challenges to making this work, however. These include validation - since the customer must verify at least once who they are, and typically the certificate cannot be delivered F2F, as well as interoperability. Why should we ask the customer, agent, or employee to obtain a certificate, if they cannot use it elsewhere. Alternatively, why cant they use their cert that they already have from XXXYYY CA?

But the biggest challenge is getting employees to understand how to operate, and regard the CA. If it's not done carefully, it's of little more use than cookies or simple http authentication.

Interoperability is a topic, I've been looking at for another article in this section.

[ Parent ]

Price (5.00 / 1) (#37)
by Bad Harmony on Sat Jun 08, 2002 at 12:52:38 PM EST

Why can't I get a client or server cert without paying an obscene amount of money to some faceless corporation that disclaims all liability?

5440' or Fight!

You can get a client cert free (4.50 / 2) (#42)
by imrdkl on Sat Jun 08, 2002 at 06:20:44 PM EST

the Thawte Web of Trust is one place that offers them.

Server certs, otoh, are still too pricey. A certain amount seems fair, since server certs do carry a certain assurance as well as insurance, but not 500 bucks. That's highway robbery.

[ Parent ]

Speaking of Thawte's Web of Trust... (none / 0) (#46)
by mcherm on Mon Jun 10, 2002 at 08:16:48 AM EST

Speaking of Thawte's Web of Trust, I signed up for a certificate 2 weeks ago. Would anyone living in the Philadelphia area be interested in a mutual authorization party?

-- Michael Chermside
[ Parent ]
Self-Signed Certificates for IIS (4.00 / 1) (#40)
by levsen on Sat Jun 08, 2002 at 05:30:41 PM EST

Does anyone know how I can create a server certificate for IIS (version 5.1) myself, using OpenSSL or something similar? I really don't need a $1000 certificate from VeriSign or one of the other crooks. I know all my clients (in the technical as well as the business sense), so I can just pass the certificate around by floppy disk.

The stupid thing is I already managed to do it once by futzing around with OpenSSL, I just can't reproduce it anymore. I remember that IIS won't accept a self-signed certificate, so I'd have to create my own root certificate and a second server certificate and sign the latter with the first.

I'll give you $10 for the answer.

This comment is printed on 100% recycled electrons.

Watch for my next article (4.00 / 1) (#41)
by imrdkl on Sat Jun 08, 2002 at 06:05:34 PM EST

All will be revealed.

[ Parent ]
Google answers (5.00 / 1) (#45)
by ebatsky on Sat Jun 08, 2002 at 08:04:37 PM EST

If you're willing to pay $10 to get answer to that question, you might want to try going to http://answers.google.com.

It's usually very good at answering questions such as yours.

[ Parent ]

Whooho I did it! (none / 0) (#50)
by levsen on Fri Jun 14, 2002 at 05:35:30 PM EST

You can read the question here. The amazing thing is someone wrote a reply 1 minute later. Go check it out.
This comment is printed on 100% recycled electrons.
[ Parent ]
Digital Certificates: place your order | 50 comments (42 topical, 8 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!