How to create / embed a CSP into Basiccard, or any smartcard so i can log in a domain

Ok call me stupid but how can you have the CA server not even connected to the network, how then can it be communicated with to verify the certs?

I already said that the Basiccard devs are not prepared to develop a CSP for their card so that is out of the question.

I think the sensible thing to do would be to by another smartcard type i have the reader so do you have any suggestions on what kind of smartcard would allow for all the highest security functionality but also be easy(or relatively easy) to set up, i.e it has the CSP's avaiilable or better still windows 2003/2008 supports it by default, or even better still a card that has a clear walkthough guiade online for setting it up.

cheers

The root CA should be kept offline for security reasons.  You can't revoke a root cert (since it is self-signed) and re-deploying it is a pain in most cases.

So the root Ca only issues the 2nd tier CA certificates (usually an online subordinate CA, although sometimes additional tiers may exist for specific situtations).   You have to sneakernet the CRL, certificate request files, etc. back and forth to the offline root CA - use a floppy, flash drive, etc.

When you install the root in 2008 the CDP (CRL Distribution Point) and AIA (Authority Information Access) locations are defined as empty so the root cert will not include them.  In 2003, you had to use a capolicy.inf file in c:\windows to define certain settings such as this.  Afterwards, you open the CA MMC and define the CDP and AIA locations that will be used to verify the sub CA cert.  On the sub CA you will do the same after installation to define where "end entity" (users, computers, etc.) certs are validated against.  When the cert is issued, the configured CDP and AIA locations are included into the certificate as URLs.

When the trusting client (end user checking to see if the cert is good or not) then the browser or other app will have a "certificate chaining engine" that will check through all this stuff for you and either give you a warning or display the nice little gold padlock.  

The chaining engine will check the local machine (registry, certificate store, etc.) and the cert's AIA to locate the CA cert that issued the cert it is validating.  That CA's cert will have an AIA that will then be checked and so on up until the root cert.  The root _should_ be trusted by the client already in the Trusted Root Certification Authorities certificate store, if not then a warning pops up about the issuer not being trusted.  Since you trust the root, you  trust everything downline from it.  That's how you make sure it is trusted as being authentic.

Next is to make sure it hasn't been revoked.  Maybe the server was compromised and the private key stolen.  Maybe the employee got fired.  Whatever the reason, you need to make sure you should still trust it.  In the cert is the CDP, which is a URL that points to the CRL (Certificate Revocation List).  This list is signed by the CA that issued that cert and is updated on a predefined interval which varies greatly from hourly/daily/weekly/monthly - depends on the company.  Since it is CA signed, you trust its authenticity.

The CRL contains a list of serial numbers and dates - if the cert's serial number ends up on that list then it has been revoked, otherwise it should be considered still valid.

Then comes validating a few other things like comparing the subject name of the cert to the site you are accessing in the URL (www.domain.com -- doesn't matter what virtual directory or page is listed afterwards), or the email address - to make sure this is the same.  

The program does all this for you.  Aren't we glad:)

So the server cert and CRL are stored in the AIA and CDP locations (respectively) which is usually on a web server.  The offline CA items are usually copied to the online CA, then they are usually copied together via script, or manually using a floppy, etc. to the web server.  They are then accessed there via the cert chaining engine and everything processed and you're all good.


OK - that's a whole bunch of stuff there...  hope your head isn't spinning too fast...

Amazing answers, some of it was way over my head though obvioulsy will give you the points, do i accept a single answer or multple answers, does it matter?

Doesn't really matter to me - I'm just here to help.  Since they're all mine the points all add up the same either way.

Here's a more streamlined version, not sure if it makes things any better:

root ca signs sub ca
sub ca signs end entity cert
user's program trusts root cert due to user installing the root cert (or installed with software, which you trust the vendor to include trustworthy roots in their product)
program validates cert is signed by sub ca
program validates sub ca is signed by root ca
root is trusted, so all of the certificate chain is now trusted.

program checks CRL to make sure cert is not revoked
program checks cert's subject name to make sure it matches what you are validating

If SSL is involved, cert is used for the handshake to create a "password" (secret key) for the SSL encryption session only known to the computer and server on a per session basis
Data is encrypted and decrypted using the SSL session's key

For SC logon, cert is validated against AD
Kerberos TGT is issued to user logon session.