public void createKeyStore() {







try {







KeyGenerator keyGen = KeyGenerator.getInstance("DES");















SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");















keyGen.init(56, random);















SecretKey secretKey = keyGen.generateKey();















KeyStore ks = KeyStore.getInstance("jceks");















char password[] = {'c', 'h', 'a', 'n', 'g', 'e','i','t' };















// Create an empty keystore







ks.load(null, password);















KeyStore.SecretKeyEntry skEntry = new KeyStore.SecretKeyEntry(secretKey);















ks.setEntry("myKey", skEntry, new KeyStore.PasswordProtection(password));







 







// store away the keystore







java.io.FileOutputStream fos =







new java.io.FileOutputStream("mystore");







ks.store(fos, password);







fos.close();















} catch (NoSuchAlgorithmException nsaex) {







nsaex.printStackTrace(System.err);







} catch (NoSuchProviderException nspex) {







nspex.printStackTrace(System.err);







} catch (KeyStoreException ksex) {







ksex.printStackTrace(System.err);







} catch (CertificateException cex) {







cex.printStackTrace(System.err);







} catch (IOException ioex) {







ioex.printStackTrace(System.err);







}







}















上面的例子是存一个DES密钥。







需要注意的就是这个keystore的类型，必须是jceks，







之前我就是使用默认的jks，导致报错。 

    CAPICOM_ACTIVE_DIRECTORY_USER_STORE 3 得到AD上已经发布的证书
    CAPICOM_CURRENT_USER_STORE 2 得到当前用户的证书
    CAPICOM_LOCAL_MACHINE_STORE 1 得到本地机器上的证书
    CAPICOM_MEMORY_STORE 0 得到内存中的证书
StoreName :
    CAPICOM_MY_STORE "MY" 得到当前用户证书与CAPICOM_CURRENT_USER_STORE配合使用
    "CN=your user name on domain" 得到指定用户的证书,一般与CAPICOM_ACTIVE_DIRECTORY_USER_STORE配合使用.
OpenMode:    
    CAPICOM_STORE_OPEN_READ_ONLY 0 只读方法

经常易出错的地方是:以上这些常量在vbscript中并没被预定义,使用前要自己定义一下.其值就是后面相应的数字.
之前我就是以为这此常量是VBS预定义了,所以直接用,导致操作不成功,浪费了大量时间去找原因.
当然,你也可以直接用相应数字代替这此常量.

了解更多请参考:
http://msdn.microsoft.com/en-us/library/aa388130.aspx
http://207.46.196.114/windowsserver/en/library/8f918fdc-9841-48f9-a46d-28232742239a1033.mspx?mfr=true

INTRODUCTION

MORE INFORMATION

Registry entries and values under the Parameters key

Registry entries and values under the Kdc key

目前，CAPICOM共有两个版本：1.0版和 2.0版。其中，后者在前者的基础上，提供了一些额外的功能。

CAPICOM v1.0提供如下功能：

1、产生和验证PKCS#7格式的数字签名；

2、使用证书加密/解密数据；

3、使用口令加密/解密数据；

CAPICOM v2.0额外提供如下功能：

1、产生和验证代码签名；

2、支持文件形式的证书；

3、快速证书搜索；

4、产生任意数据的哈希值；

5、支持AES算法（需要Windows .NET Server 2003 或 Windows XP支持）；

6、支持高级证书属性，例如：政策、模板。

CAPICOM是重分发组件，也就是说它没有被包含在操作系统的中，需要单独安装注册该组件（可以从MS那里免费下载）；CAPICOM v1.0 要求Win95、WinNT 4.0或更高版本，CAPICOM v2.0 要求Win98 、WinNT 4.0 + SP4 或更高版本

在MSDN中有对CAPICOM的详细描述，以下提供两个连接地址：

CAPICOM使用参考：msdn""Security"" Security(General)""SDK Documentation""Cryptography"" Cryptography Reference""CAPICOM Reference

CAPICOM例子程序：msdn""Security"" Security(General)""SDK Documentation""Cryptography""

Using Cryptography""Using CAPICOM

下载最新的CAPICOM：

http://download.microsoft.com/download/7/7/0/7708ec16-a770-4777-8b85-0fcd05f5ba60/CC2RINST.EXE

使用 Setspn.exe

下面是使用 Setspn.exe 命令行实用程序的基本语法，其中“accountname”可以是单独的名称，也可以是域\名称。

setspn [parameter] accountname

Setspn.exe 可以使用下列参数：

下面的示例使用 Setspn.exe 命令行实用程序注册以 Domain\UserAccount 运行的应用程序池：

SETSPN.EXE -A HOST/<your computer name> Domain\UserAccount

下面的示例注册 SPN“HOST/daserver1”和“HOST/{DNS of daserver1}”：

setspn -R daserver1

下面的示例为计算机“daserver1”注册 SPN“http/daserver”：

setspn -A http/daserver daserver1

下面的示例从计算机“daserver1”删除 SPN“http/daserver”：

setspn -D http/daserver daserver1

下面我来介绍一下这kerberos协议如何实现认证的.
前提:client和server都在kdc上已注册.
第一步 Authentication Service Exchange
第二步 Ticket Granting Service Exchange
第三步 Client/Server Exchange
  首先Client向kdc申请server服务,kdc查看server服务是受保护的服务,所以要验证client的身份,这就是第一步,kdc验证client的身份(Authentication Service Exchange).当kdc核实client的身份正确后,会给client一个证明,用这个证明我们可以得到访问server服务的许可证(Ticket),所以我们把这个证明叫做TGT(Ticket Granting Ticket).
当client得到TGT后,用TGT来向kdc索要访问server服务的通行证(Ticket),这就是第二步Ticket Granting Service Exchange.
当client得到通行证(Ticket)后,就与server交互,向server出示通行证(Ticket),即第三步Client/Server Exchange,从可得到server的服务.
以上三步的具体实现要复杂得多,简单介绍如下:
1． Authentication Service Exchange

通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如

下：

Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，

Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。

KRB_AS_REQ的大体包含以下的内容：

Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是

一个被Client的Master key加密过的Timestamp。
Client name & realm: 简单地说就是Domain name\Client Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说

了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是

否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法

的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response（KRB_AS_REP

）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（

SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容

：

Session Key: SKDC-Client：Logon Session Key
Client name & realm: 简单地说就是Domain

name\Client
End time: TGT到期的时间。
Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步：TGS（

Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request

（KRB_TGS_REQ）开始。KRB_TGS_REQ大体包含以下的内容：

TGT：Client通过AS Exchange获得的Ticket

Granting Ticket，TGT被KDC的Master Key进行加

密。
Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自己的Session Key（SKDC-Client：Logon Session Key

）来进行加密。
Client name & realm: 简单地说就是Domain name\Client。
Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。
TGS收到KRB_TGS_REQ在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的

Authenticator来证明。但是Authentication是通过Logon Session Key（SKDC-Client）进行加密的，而自己并没有保存这个Session Key。所以

TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key（SKDC-Client），再通过这个Logon Session

Key（SKDC-Client）解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有

两部分组成：使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client）和使用Server的Master

Key进行加密的Ticket。该Ticket大体包含以下一些内容：

Session Key：SServer-Client。
Client name & realm: 简单地说就是Domain name\Client。
End time: Ticket的到期时间。
Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client）。有了Session Key和

Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人了。所以我们说Kerberos是一种高效的认证方式，它可以直接通

过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。

我们现在来看看 Client如果使用Ticket和Server怎样进行交互的，这个阶段通过我们的第3个Sub-protocol来完成：CS（Client/Server ）

Exchange。

3． CS（Client/Server ）Exchange

Client通过TGSExchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（KRB_AP_REQ）发

送给Server。除了上述两项内容之外，KRB_AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。通过Session Key（SServer

-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于

Client验证Server的身份。

想要更深入的理解kerberos,请参考官方网站

http://web.mit.edu/Kerberos/