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);
}
}
上面的例子是存(sh)个DES密钥?br />
需要注意的是q个keystore的类型，必须是jceksQ?br />
之前我就是用默认的jksQ导致报错?
]]>
This
article contains information about registry entries that relate to the
Kerberos version 5 authentication protocol in Microsoft Windows Server
2003.
INTRODUCTION
Kerberos is an authentication mechanism that is used to
verify user or host identity. Kerberos is the preferred authentication method
for services in Windows Server 2003.
If you are running Windows Server 2003, you can modify Kerberos parameters to help troubleshoot Kerberos authentication issues or to test the Kerberos protocol. To do this, add or modify the registry entries that are listed in the "More Information" section.
If you are running Windows Server 2003, you can modify Kerberos parameters to help troubleshoot Kerberos authentication issues or to test the Kerberos protocol. To do this, add or modify the registry entries that are listed in the "More Information" section.
MORE INFORMATION
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:322756 (http://support.microsoft.com/kb/322756/) How to back up and restore the registry in Windows
Note After you finish troubleshooting or testing the Kerberos
protocol, remove any registry entries that you add. Otherwise, performance of
your computer may be affected.
Registry entries and values under the Parameters key
The registry entries that are listed in this section must be added to the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Note If the Parameters key is not listed under Kerberos, you must
create the key.
| • | Entry: SkewTime Type: REG_DWORD Default Value: 5 (minutes) This value is the maximum time difference that is permitted between the client computer and the server that accepts Kerberos authentication. In Windows 2000 checked build version, the default SkewTime value is 2 hours. Note A checked build version of the Windows operating system is used in production and testing environments. (A checked build is also known as a debug version.) A checked build has many compiler optimizations turned off. This kind of build helps trace the cause of problems in system software. A checked build turns on many debugging checks in the operating system code and in the system drivers. These debugging checks help the checked build identify internal inconsistencies as soon as they occur. A checked build is larger and is slower to run than an end-user version of Windows. An end-user version of Windows is also known as a free build version or a retail-build version. In a free build version, debugging information is removed, and Windows is built with full compiler optimizations. A free build version is faster and uses less memory than a checked build version. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: LogLevel Type: REG_DWORD Default Value: 0 This value indicates whether events are logged in the system event log. If this value is set to any non-zero value, all Kerberos-related events are logged in the system event log. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: MaxPacketSize Type: REG_DWORD Default Value: 1465 (bytes) This value is the maximum User Datagram Protocol (UDP) packet size. If the packet size exceeds this value, TCP is used. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: StartupTime Type: REG_DWORD Default Value: 120 (seconds) This value is the time that Windows waits for the Key Distribution Center (KDC) to start before Windows gives up. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: KdcWaitTime Type: REG_DWORD Default Value: 10 (seconds) This value is the time Windows waits for a response from a KDC. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: KdcBackoffTime Type: REG_DWORD Default Value: 10 (seconds) This value is the time between successive calls to the KDC if the previous call failed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: KdcSendRetries Type: REG_DWORD Default Value: 3 This value is the number of times that a client will try to contact a KDC. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: DefaultEncryptionType Type: REG_DWORD Default Value: 23 (decimal) or 0x17 (hexadecimal) This value indicates the default encryption type for pre-authentication. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: FarKdcTimeout Type: REG_DWORD Default Value: 10 (minutes) This is the time-out value that is used to invalidate a domain controller from a different site in the domain controller cache. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: NearKdcTimeout Type: REG_DWORD Default Value: 30 (minutes) This is the time-out value that is used to invalidate a domain controller in the same site in the domain controller cache. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: StronglyEncryptDatagram Type: REG_BOOL Default Value: FALSE This value contains a flag that indicates whether to use 128-bit encryption for datagram packets. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: MaxReferralCount Type: REG_DWORD Default Value: 6 This value is the number of KDC referrals that a client pursues before the client gives up. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: KerbDebugLevel Type: REG_DWORD Default Value: 0xFFFFFFFF This value is a list of flags that indicate the type and the level of logging that is requested. This kind of logging can be collected on the component level of Kerberos by bitwise or by one or more of the macros that are described in the following table.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: MaxTokenSize Type: REG_DWORD Default Value: 12000 (Decimal) This value is the maximum value of the Kerberos token. Microsoft recommends that you set this value to less than 65535. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: SpnCacheTimeout Type: REG_DWORD Default Value: 15 minutes This value is the lifetime of the Service Principal Names (SPN) cache entries. On domain controllers, the SPN cache is disabled. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: S4UCacheTimeout Type: REG_DWORD Default Value: 15 minutes This value is the lifetime of the S4U negative cache entries that are used to restrict the number of S4U proxy requests from a particular computer. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: S4UTicketLifetime Type: REG_DWORD Default Value: 15 minutes This value is the lifetime of tickets that are obtained by S4U proxy requests. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: RetryPdc Type: REG_DWORD Default Value: 0 (false) Possible values: 0 (false) or any non-zero value (true) This value indicates whether the client will contact the primary domain controller for Authentication Service Requests (AS_REQ) if the client receives a password expiration error. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: RequestOptions Type: REG_DWORD Default Value: Any RFC 1510 value This value indicates whether there are additional options that must be sent as KDC options in Ticket Granting Service requests (TGS_REQ). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: ClientIpAddress Type: REG_DWORD Default Value: 0 (This setting is 0 because of Dynamic Host Configuration Protocol and network address translation issues.) Possible values: 0 (false) or any non-zero value (true) This value indicates whether a client IP address will be added in AS_REQ to force the Caddr field to contain IP addresses in all tickets. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: TgtRenewalTime Type: REG_DWORD Default Value: 600 seconds This value is the time that Kerberos waits before it tries to renew a Ticket Granting Ticket (TGT) before the ticket expires. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| • | Entry: AllowTgtSessionKey Type: REG_DWORD Default Value: 0 Possible values: 0 (false) or any non-zero value (true) This value indicates whether session keys are exported with initial or with cross realm TGT authentication. The default value is false for security reasons. |
Registry entries and values under the Kdc key
The registry entries that are listed in this section must be added to the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Note If the Kdc key is not listed under Services, you must create the
key.
| • | Entry: KdcUseClientAddresses Type: REG_DWORD Default Value: 0 Possible values: 0 (false) or any non-zero value (true) This value indicates whether IP addresses will be added in the Ticket-Granting Service Reply (TGS_REP). |
||||||
| • | Entry: KdcDontCheckAddresses Type: REG_DWORD Default Value: 1 Possible values: 0 (false) or any non-zero value (true) This value indicates whether IP addresses for the TGS_REQ and the TGT Caddr field will be checked. |
||||||
| • | Entry: NewConnectionTimeout Type: REG_DWORD Default Value: 50 (seconds) This value is the time that an initial TCP endpoint connection will be kept open to receive data before it disconnects. |
||||||
| • | Entry: MaxDatagramReplySize Type: REG_DWORD Default Value: 1465 (decimal, bytes) This value is the maximum UDP packet size in TGS_REP and Authentication Service Replies (AS_REP) messages. If the packet size exceeds this value, the KDC returns a KRB_ERR_RESPONSE_TOO_BIG message that requests that the client switch to TCP. |
||||||
| • | Entry: KdcExtraLogLevel Type: REG_DWORD Default Value: 2 Possible values:
|
||||||
| • | Entry: KdcDebugLevel Type: REG_DWORD Default Value: 1 for checked build, 0 for free build This value indicates whether debug logging is on (1) or off (0). If the value is set to 0x10000000 (hexadecimal) or 268435456 (decimal), specific file or line information will be returned in the edata field of KERB_ERRORS as PKERB_EXT_ERROR errors during a KDC processing failure. 摘自Qhttp://support.microsoft.com/?scid=kb%3Ben-us%3B837361&x=11&y=18 |
]]>
Windowspȝ中的安全lg.
CAPICOM是一?/span>COM模型的组Ӟ可以?/span>Windows环境下各U语a中用。而且Q?/span>CAPICOM中的大多数接口都?#8220;脚本安全”的，q意味着你可以在览器网脚本中安全C用这些接口所提供的功能?/span>
目前Q?/span>CAPICOM共有两个版本Q?/span>1.0版和 2.0版。其中，后者在前者的基础上，提供?jin)一些额外的功能?/span>
CAPICOM v1.0提供如下功能Q?/span>
1?span style="font-family: ?hu)?">产生和验?/span>PKCS#7格式的数字签名；
2?span style="font-family: ?hu)?">使用证书加密
/解密数据Q?/span>3?span style="font-family: ?hu)?">使用口o(h)加密
/解密数据Q?/span>
CAPICOM v2.0额外提供如下功能Q?/span>
1?span style="font-family: ?hu)?">产生和验证代码签名；
2?span style="font-family: ?hu)?">支持文g形式的证书；
3?span style="font-family: ?hu)?">快速证书搜索；
4?span style="font-family: ?hu)?">产生L数据的哈希|
5?span style="font-family: ?hu)?">支持AES法Q需?/span>Windows .NET Server 2003 ?/span> Windows XP支持Q；
6?span style="font-family: ?hu)?">支持高证书属性，例如Q政{、模ѝ?/span>
CAPICOM是重分发lgQ也是说它没有被包含在操作pȝ的中Q需要单独安装注册该lgQ可以从MS那里免费下蝲Q；CAPICOM v1.0 要求Win95?/span>WinNT 4.0或更高版本，CAPICOM v2.0 要求Win98 ?/span>WinNT 4.0 + SP4 或更高版?/span>
?/span>MSDN中有?/span>CAPICOM的详l描qͼ以下提供两个q接地址Q?/span>
CAPICOM使用参考：(x)msdn""Security"" Security(General)""SDK Documentation""Cryptography"" Cryptography Reference""CAPICOM Reference
CAPICOM例子E序Q?/span>msdn""Security"" Security(General)""SDK Documentation""Cryptography""
Using Cryptography""Using CAPICOM
下蝲最新的CAPICOMQ?/span>
http://download.microsoft.com/download/7/7/0/7708ec16-a770-4777-8b85-0fcd05f5ba60/CC2RINST.EXE
摘自:http://blog.csdn.net/brave1/archive/2005/06/07/389778.aspx]]>
使用 Setspn.exe
下面是?Setspn.exe 命o(h)行实用程序的基本语法Q其?#8220;accountname”可以是单独的名称Q也可以是域\名称?/p>
setspn [parameter] accountname
Setspn.exe 可以使用下列参数Q?/p>
| 参数 | 功能 | CZ |
|---|---|---|
| -R | 重置 HOST ServicePrincipalName?/td> | setspn -R computername |
| -A | dL?SPN?/td> | setspn -A SPN computername |
| -D | 删除L?SPN?/td> | setspn -D SPN computername |
| -L | 列出已注册的 SPN?/td> | setspn -L SPN computername |
下面的示例?Setspn.exe 命o(h)行实用程序注册以 Domain\UserAccount q行的应用程序池Q?/p>
SETSPN.EXE -A HOST/<your computer name> Domain\UserAccount下面的示例注?SPN“HOST/daserver1”?#8220;HOST/{DNS of daserver1}”Q?/p>
setspn -R daserver1下面的示例ؓ(f)计算?#8220;daserver1”注册 SPN“http/daserver”Q?/p>
setspn -A http/daserver daserver1下面的示例从计算?#8220;daserver1”删除 SPN“http/daserver”Q?/p>
setspn -D http/daserver daserver1]]>
如果在安装Windows Server 2003q程中，没有选择DNSlgQ默认情况下是不被安装的Q我们就需要手动去d它。这里我们需要用到Windows Server 2003的安装光盘?br /> dҎ(gu)如下:
“开始—设|—控刉李(k)添加删除程?#8221;Q?br /> 然后再点?#8220;d/删除Windowslg”
选中“|络服务”
默认情况下所有的|络服务都会(x)被添加，可以点击下面?#8220;详细信息”q行自定义安装，׃在这里只需要DNSQ所以把其它的全都去掉了(jin)Q以后需要的时候再安装
然后是?#8220;定”Q一直点“下一?#8221;可以完成整个DNS的安装。在整个安装q程中请保证Windows Server 2003安装光盘?sh)于光驱中，否则会(x)出现找不到文g的提C，那就需要手动定位了(jin)?br />
2QActive Directory安装
安装完DNS以后Q就可以q行提升操作?jin)，先点?#8220;开始—运?#8221;Q输?#8220;Dcpromo”Q然后回车就可以看到“Active Directory安装向导”
安装q程按照提示输入相应内容可以了(jin)Q?br /> 但是Q当?“DNS 注册诊断”q一步时Q可能出现诊断失败，W一ơ部|时M(x)出现上面那个DNS注册诊断出错的画面，主要是因然安装了(jin)DNSQ但׃q没有配|它Q网l上q没有可用的DNS服务器，所以才?x)出现响应超时的现像Q所以在q里要选择:“在这台计机上安装ƈ配置DNSQƈ这台DNS服务器设台计机的首选DNS服务?#8221;?br /> 安装完成后提C重启，
然后来看一下安装了(jin)AD后和没有安装的时候有些什么区别，首先W一感觉是x(chng)和开机的速度明显变慢?jin)?br /> 再看一下登陆界??#8220;d?#8221;选项中选择刚配|的域名Q登录?br /> 3Q检查是否成?br /> q入pȝ后，右键点击“我的?sh)?#8221;?#8220;属?#8221;Q点“计算?#8221;
如果已经d上了(jin)指定域，
q台服务器就被成功提升ؓ(f)域控制器?jin)?
]]>
kerberos是一个很重要的网l认证协?它实C(jin)在一个非安全的网l环境中,一个实体向另一个实体证实自qw䆾,从而以安全的方式进行交?kerberos protocol已经被广泛应用于各种应用?最为典型的莫过于windows中的kerberos认证,它在spnego protocol之下,为windows域用L(fng)录提供安全保?
首先相关名词:
Long term key:是长期保持不变的key.
Master key:是Long term keyl过Hashq算得到的Hash code.
Short term key:是只在一定时间内有效的key.有时也叫Session key.
原则上Long term key 是不能在|络上传输的,因ؓ(f)很可能Long term key在传输过E中被h截获,一旦它被截?原则上只要有_的时?可以被破解.另外,对于一个帐戯(g)言,密码仅限于该用户知道,对于domain的Administrator也应该保?但由于密码是用户向Administrator证明w䆾的凭?所以要Z用户的密码生成来的信息来证明用户的n?通常做法是对密码q行Hashq算,生成Hash code,q个Hash code是我们说的Master key.因ؓ(f)Hash Algorithmh不可?同时保证?jin)密码与Master key一一对应的特?保证?jin)密码的保密?也保证了(jin)Master key可以代表密码作ؓ(f)用户w䆾的凭?而作?Short term key,用来加密在网l上传输的数?׃它只在一定时间内有效,即被h截获,{到被破解时,q个key早就q期?
Client 服务h?br /> Server 服务提供?br /> KDC kerberos distribution certer.在整个认证过E中作ؓ(f)client和server共同信认的第三方.
以windows2003中的DomainZ,Domain Controller扮演着kdc的角?
下面我来介绍一下这kerberos协议如何实现认证?
前提:client和server都在kdc上已注册.
W一?Authentication Service Exchange
W二?Ticket Granting Service Exchange
W三?Client/Server Exchange
首先Client向kdc甌server服务,kdc查看server服务是受保护的服?所以要验证client的n?q就是第一?kdc验证client的n?Authentication Service Exchange).当kdc核实client的n份正后,?x)给client一个证?用这个证明我们可以得到访问server服务的许可证(Ticket),所以我们把q个证明叫做TGT(Ticket Granting Ticket).
当client得到TGT?用TGT来向kdc索要讉Kserver服务的通行?Ticket),q就是第二步Ticket Granting Service Exchange.
当client得到通行?Ticket)?׃server交互,向server出示通行?Ticket),即第三步Client/Server Exchange,从可得到server的服?
以上三步的具体实现要复杂得多,单介l如?
1Q?Authentication Service Exchange
通过q个Sub-protocolQKDCQ确切地说是KDC中的Authentication ServiceQ实现对Clientw䆾的确认，q发给该Client一个TGT。具体过E如
下：(x)
Client向KDC的Authentication Service发送Authentication Service RequestQKRB_AS_REQQ? Z(jin)保KRB_AS_REQ仅限于自己和KDC知道Q?/p>
Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master KeyQ?/p>
KRB_AS_REQ的大体包含以下的内容Q?/p>
Pre-authentication dataQ包含用以证明自pn份的信息。说白了(jin)Q就是证明自q道自己声U的那个account的Password。一般地Q它的内Ҏ(gu)
一个被Client的Master key加密q的Timestamp?br /> Client name & realm: 单地说就是Domain name\Client Server NameQ注意这里的Server Nameq不是Client真正要访问的Server的名Uͼ而我们也?/p>
?jin)TGT是和Server无关的（Client只能使用TicketQ而不是TGT去访问ServerQ。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name?br /> ASQAuthentication ServiceQ通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声U的那个人，也就是说要验证发送放?/p>
否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication dataq行解密Q如果是一个合?/p>
的TimestampQ则可以证明发送放提供的是正确无误的密码。验证通过之后QAS一份Authentication Service ResponseQKRB_AS_REP
Q发送给C(j)lient。KRB_AS_REQ主要包含两个部分Q本Client的Master Key加密q的Session KeyQ?/p>
SKDC-ClientQLogon Session KeyQ和被自己（KDCQ加密的TGT。而TGT大体又包含以下的内容
Q?/p>
Session Key: SKDC-ClientQLogon Session Key
Client name & realm: 单地说就是Domain
name\Client
End time: TGT到期的时间?br />
Client通过自己的Master Key对第一部分解密获得Session KeyQSKDC-ClientQLogon Session KeyQ之后，携带着TGT便可以进入下一步：(x)TGSQ?/p>
Ticket Granting ServiceQExchange?/p>
2Q?TGSQTicket Granting ServiceQExchange
TGSQTicket Granting ServiceQExchange通过Client向KDC中的TGSQTicket Granting ServiceQ发送Ticket Granting Service Request
QKRB_TGS_REQQ开始。KRB_TGS_REQ大体包含以下的内容：(x)
TGTQClient通过AS Exchange获得的Ticket
Granting TicketQTGT被KDC的Master Keyq行?/p>
密?br /> AuthenticatorQ用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自qSession KeyQSKDC-ClientQLogon Session Key
Q来q行加密?br /> Client name & realm: 单地说就是Domain name\Client?br /> Server name & realm: 单地说就是Domain name\ServerQ这回是Client试图讉K的那个Server?br /> TGS收到KRB_TGS_REQ在发lC(j)lient真正的Ticket之前Q先得整个Client提供的那个TGT是否是AS颁发l它的。于是它不得不通过Client提供?/p>
Authenticator来证明。但是Authentication是通过Logon Session KeyQSKDC-ClientQ进行加密的Q而自己ƈ没有保存q个Session Key。所?/p>
TGS先得通过自己的Master Key对Client提供的TGTq行解密Q从而获得这个Logon Session KeyQSKDC-ClientQ，再通过q个Logon Session
KeyQSKDC-ClientQ解密Authenticatorq行验证。验证通过向对方发送Ticket Granting Service ResponseQKRB_TGS_REPQ。这个KRB_TGS_REP?/p>
两部分组成：(x)使用Logon Session KeyQSKDC-ClientQ加密过用于Client和Server的Session KeyQSServer-ClientQ和使用Server的Master
Keyq行加密的Ticket。该Ticket大体包含以下一些内容：(x)
Session KeyQSServer-Client?br /> Client name & realm: 单地说就是Domain name\Client?br /> End time: Ticket的到期时间?br /> Client收到KRB_TGS_REPQ用Logon Session KeyQSKDC-ClientQ解密第一部分后获得Session KeyQSServer-ClientQ。有?jin)Session Key?/p>
TicketQClient可以之间和Serverq行交互Q而无d通过KDC作中间h?jin)。所以我们说Kerberos是一U高效的认证方式Q它可以直接?/p>
qClient和Server双方来完成，不像Windows NT 4下的NTLM认证方式Q每ơ认证都要通过一个双方信ȝW?Ҏ(gu)完成?/p>
我们现在来看?Client如果使用Ticket和Server怎样q行交互的，q个阶段通过我们的第3个Sub-protocol来完成：(x)CSQClient/Server Q?/p>
Exchange?/p>
3Q?CSQClient/Server QExchange
Client通过TGSExchange获得Client和Server的Session KeyQSServer-ClientQ，随后创徏用于证明自己是Ticket的真正所有者的AuthenticatorQƈ使用Session KeyQSServer-ClientQ进行加密。最后将q个被加密过的Authenticator和Ticket作ؓ(f)Application Service RequestQKRB_AP_REQQ发
送给Server。除?jin)上qC内容之外，KRB_AP_REQq包含一个Flag用于表示Client是否需要进行双向验证（Mutual AuthenticationQ?/p>
Server接收到KRB_AP_REQ之后Q通过自己的Master Key解密TicketQ从而获得Session KeyQSServer-ClientQ。通过Session KeyQSServer
-ClientQ解密AuthenticatorQ进而验证对方的w䆾。验证成功，让Client讉K需要访问的资源Q否则直接拒l对方的h?/p>
对于需要进行双向验证，Server从Authenticator提取TimestampQ用Session KeyQSServer-ClientQ进行加密，q将其发送给C(j)lient用于
Client验证Server的n份?/p>
惌更深入的理解kerberos,请参考官方网?/p>
http://web.mit.edu/Kerberos/
]]>
keytool -genkey -alias mykeypair -keypass mykeypairpwd
q程如下Q?br /> liqingfeng@liqingfeng:~/WORK_APP/keytooltest$ keytool -genkey -alias mykeypair -keypass mykeypairpwd
输入keystore密码Q?nbsp; 123456
(zhn)的名字与姓氏是什么？
[Unknown]Q?nbsp; fingki
(zhn)的l织单位名称是什么？
[Unknown]Q?nbsp; server
(zhn)的l织名称是什么？
[Unknown]Q?nbsp; server
(zhn)所在的城市(jng)或区域名U是什么？
[Unknown]Q?nbsp; bj
(zhn)所在的州或省䆾名称是什么？
[Unknown]Q?nbsp; bj
该单位的两字母国家代码是什?br /> [Unknown]Q?nbsp; CN
CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN 正确吗？
[否]Q?nbsp; y
liqingfeng@liqingfeng:~/WORK_APP/keytooltest$
q样生一个keypair,同时产生一个keystore.默认名是.keystore,存放到user-home目录
假如你想修改密码,可以?keytool -keypasswd -alias mykeypair -keypass mykeypairpwd -new newpass
2Q生一个密钥对Q存攑֜指定的keystore中（加上-keystore 参数Q?br /> keytool -genkey -alias mykeypair -keypass mykeypairpwd -keystore mykeystore
q程与上面的相同?br /> 执行完后Q在当前目录下生一个名为mykeystore的keystoreQ里面有一个别名ؓ(f)mykeypair的keypair?br />
3Q检查一个keystore中的内容
keytool -list -v -alias mykeypair -keystore mykeystore
参数 -v指明要列?gu)l信?br /> -alias指明列出指定的别名ؓ(f)mykeypair的keypair信息Q不指定则列出所有）(j)
-keystore指明要列出名字ؓ(f)mykeystore的keystore中的信息
q程如下Q?br /> liqingfeng@liqingfeng:~/WORK_APP/keytooltest$ keytool -list -v -keystore mykeystore
输入keystore密码Q?nbsp; 123456
Keystore cdQ?jks
Keystore 提供者：(x) SUN
(zhn)的 keystore 包含 1 输入
别名名称Q?mykeypair
创徏日期Q?2008-4-16
输入cdQKeyEntry
认证N度：(x) 1
认证 [1]:
Owner: CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN
发照者：(x) CN=fingki, OU=server, O=server, L=bj, ST=bj, C=CN
序号Q?48058c3c
有效期间Q?Wed Apr 16 13:18:52 GMT+08:00 2008 臻I(x) Tue Jul 15 13:18:52 GMT+08:00 2008
认证指纹Q?br /> MD5Q?nbsp; FD:C3:97:DC:84:A0:D8:B2:08:6F:26:7F:31:33:C3:05
SHA1Q?A3:21:6F:C6:FB:5F:F5:2D:03:DA:71:8C:D3:67:9D:1C:E1:27:A5:11
*******************************************
*******************************************
liqingfeng@liqingfeng:~/WORK_APP/keytooltest$
4QKeystore的?
当?genkey ?import?identitydb命o(h)d数据C个keystore,而当q个keystore不存在时,产生一个keystore.默认名是.keystore,存放到user-home目录.
当用-keystore指定?生指定的keystore.
5QKeystore的实?
Keytool cM于java.security包下,提供一个非常好的接口去取得和修改一个keystore中的信息. 目前有两个命令行:keytool和jarsinger,一个GUI工具Policy 可以实现keystore.׃keystore是公开?用户可以用它写一些额外的安全应用E序.
Keystoreq有一个sun公司提供的內在实?它把keystore作ؓ(f)一个文件来实现.利用?jin)一个keystorecd(格式)"JKS".它用单独的密码保护每一个私有钥?也用可能不同的密码保护整个keystore的完整?
支持的算法和钥匙大小:
keytool允许用户指定钥匙对和注册密码服务供应者所提供的签名算?~省的钥匙对产生法?DSA".假如U有钥匙?DSA"cd,~省{法?SHA1withDSA",假如U有钥匙?RSA"cd,~省法?MD5withRSA".
当生一个DSA钥匙?钥匙必须?12-1024位之?对Q何算法的~省钥匙大小?024?
6Q关于证?br /> 一个证书是一个实体的数字{,q包含这个实体的公共钥匙?
公共钥匙 :是一个详l的实体的数字关?q有意让所有想同这个实体发生信dpȝ其他实体知道.公共钥匙用来(g)验签?
数字{:是实体信息用实体的私有钥匙签名（加密Q后的数?q条数据可以用这个实体的公共钥匙来检验签名（解密Q出实体信息以鉴别实体的w䆾;
{:用实体私有钥匙加密某些消息，从而得到加密数?
U有钥匙:是一些数?U有和公共钥匙存在所有用公共钥匙加密的系l的钥匙对中.公共钥匙用来加密数据Q私有钥匙用来计签?公钥加密的消息只能用U钥解密Q私钥签名的消息只能用公钥检验签名?br /> 实体:一个实体可以是一个h,一个组l?一个程?一台计机,一个商?一个银?或其他你想信ȝ东西.
实际上，我们用E1Q中的命令已l生成了(jin)一个自{的证书，没有指定的参数都使用的是默认倹{?br /> 我们也可以用如下命o(h)生成一个自{的证书：(x)
keytool -genkey -dname "CN=fingki,OU=server,O=server,L=bj,ST=bj,C=CN" -alias myCA -keyalg RSA -keysize 1024 -keystore myCALib -keypass 654321 -storepass 123456 -validity 3650
q条命o(h)生成一个别名ؓ(f)myCA的自{证书Q证书的keypair的密码ؓ(f)654321Q证书中实体信息?"CN=fingki,OU=server,O=server,L=bj,ST=bj,C=CN"Q存储在名ؓ(f)myCALib的keystore中（如果没有自动生成一个）(j)Q这个keystore的密码ؓ(f)123456Q密钥对产生的算法指定ؓ(f)RSAQ有效期?0q?br /> 7Q将证书导出到证书文?br /> keytool -export -alias myCA -file myCA.cer -keystore myCALib -storepass 123456 -rfc
使用该命令从名ؓ(f)myCALib的keystore中，把别名ؓ(f)myCA的证书导出到证书文gmyCA.cer中?其中-storepass指定keystore的密码，-rfc指定以可查看~码的方式输出，可省??
8Q通过证书文g查看证书信息
keytool -printcert -file myCA.cer
9Q密钥库中证书条目口令的修改
Keytool -keypasswd -alias myCA -keypass 654321 -new newpass -storepass 123456 -keystore myCALib
10Q删除密钥库中的证书条目
keytool -delete -alias myCA -keystore myCALib
11Q把一个证书文件导入到指定的密钥库
keytool -import -alias myCA -file myCA.cer -keystore truststore
(如果没有名ؓ(f)truststore的keystoreQ将自动创徏,会(x)提示输入keystore的密?
12Q更改密钥库的密?br /> keytool -storepasswd -new 123456 -storepass 789012 -keystore truststore
其中-storepass指定原密码，-new指定新密码?br />
]]>
]]>