Sun Java System Application Server Enterprise Edition 8.2 管理指南

第 9 章 配置安全性

安全性是有关数据保护的功能:在存储和传输数据时如何防止对数据进行未经授权的访问或破坏。Application Server 具有基于 J2EE 标准的动态可扩展安全体系结构。内置了多种安全功能,包括密码学、验证和授权以及公钥基本结构。Application Server 是基于 Java 安全模型构建的,该安全模型使用沙箱,应用程序可以在沙箱中安全地运行,而不会给系统或用户带来潜在的危险。本节介绍了以下主题:

了解应用程序和系统安全性

从宽泛意义上讲,应用程序安全性有两种:

除了应用程序安全性以外,还有影响 Application Server 系统中所有应用程序的系统安全性

程序安全性受应用程序开发者的控制,因此本文档不对其进行讨论;声明安全性受应用程序开发者的控制要少一些,本文档中只偶尔涉及到声明安全性。本文档主要针对系统管理员,因此主要讲述了系统安全性。

管理安全性的工具

Application Server 提供了以下用于管理安全性的工具:

Java 2 Platform, Standard Edition (J2SE) 提供了两个用于管理安全性的工具:

有关使用 keytoolpolicytool 和其他 Java 安全性工具的更多信息,请参见 http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security 上的 Java 2 SDK Tools and Utilities

在 Enterprise Edition 中,还可以使用两个实现网络安全服务 (NSS) 的工具来管理安全性。有关 NSS 的更多信息,请访问 http://www.mozilla.org/projects/security/pki/nss/。管理安全性的工具包括:

有关使用 certutilpk12util 和其他 NSS 安全性工具的更多信息,请参见 http://www.mozilla.org/projects/security/pki/nss/tools 上的 NSS Security Tools

管理密码安全性

在此版本的 Application Server 中,包含特定域的规范的 domain.xml 文件最初以明文形式包含了 Sun Java System Message Queue 代理的密码。domain.xml 文件中包含此密码的元素为 jms-host 元素的 admin-password 属性。由于在安装期间不能更改此密码,因此它不会对安全性产生很大的影响。

不过,您可以使用管理控制台添加用户和资源,并为这些用户和资源指定密码。部分密码将以明文形式写入 domain.xml 文件,例如用于访问数据库的密码。将这些密码以明文形式保存在 domain.xml 文件中可能会使安全性受到威胁。您可以对 domain.xml 中的任何密码(包括 admin-password 属性或数据库密码)进行加密。有关管理安全性密码的说明,请参见以下主题:

domain.xml 文件中加密密码

要在 domain.xml 文件中加密密码,请执行以下步骤:

  1. domain.xml 文件所在的目录(默认情况下,此目录为 domain-dir/config)中,运行以下 asadmin 命令:


    asadmin create-password-alias --user admin alias-name
    

    例如,


    asadmin create-password-alias --user admin jms-password

    将显示输入密码提示(在本例中为 admin)。有关更多信息,请参阅 create-password-aliaslist-password-aliasesdelete-password-alias 命令的手册页。

  2. 删除并替换 domain.xml 中的密码。使用 asadmin set 命令可以完成此操作。用于此目的的 set 命令的示例如下:


    asadmin set --user admin server.jms-service.jms-host.
    default_JMS_host.admin-password='${ALIAS=jms-password}'

    注 –

    将别名密码括在单引号中,如本例中所示。


  3. 重新启动相关域的 Application Server。

保护具有编码密码的文件

某些文件包含需要使用文件系统权限进行保护的编码密码。这些文件包括:

更改主密码

主密码 (MP) 是全局性的共享密码。它从不用于验证,也从不会在网络上传输。此密码是整体安全性的要塞点;用户可以选择在需要时手动输入此密码,也可以将其隐藏在文件中。它是系统中最敏感的数据。用户可以通过删除此文件强制系统提示输入 MP。更改主密码时,会将其重新保存在主密码密钥库(Java JCEKS 类型的密钥库)中。

要更改主密码,请执行以下步骤:

  1. 停止域的 Application Server。使用 asadmin change-master-password 命令提示输入旧密码和新密码,然后对所有依赖项重新进行加密。例如:


    asadmin change-master-password>
    Please enter the master password>
    Please enter the new master password>
    Please enter the the new master password again>
  2. 重新启动 Application Server。


    注意 – 注意 –

    此时,不能启动正在运行的服务器实例并且不能重新启动运行服务器实例,除非已更改这些实例所对应的节点代理上的 SMP。如果在更改服务器实例的 SMP 之前重新启动了该服务器实例,它将无法启动。


  3. 一次停止一个节点代理及与其相关的服务器。再次运行 asadmin change-master-password 命令,然后重新启动节点代理及其相关服务器。

  4. 继续对下一个节点代理执行此过程,直到对所有节点代理均已执行此过程。这样就可以完成滚动更改。

使用主密码和密钥库

主密码是用于安全密钥库的密码。创建新应用服务器域时,会生成新的自签名证书并将其存储在相关密钥库中,此密钥库是使用主密码锁定的。如果主密码不是默认密码,则 start-domain 命令将提示您输入主密码。输入正确的主密码后,便会启动域。

创建与域关联的节点代理时,节点代理会将数据与域同步。执行此操作时,也会同步密钥库。由此节点代理所控制的任何服务器实例都需要打开密钥库。由于此密钥库实际上与域创建进程所创建的密钥库相同,因此只能使用相同的主密码将其打开。不过主密码本身从未同步,这意味着不会在同步过程中将其传输到节点代理,但是需要在本地为节点代理提供主密码。因此在创建和/或启动节点代理时会提示您输入主密码,并且您需要输入创建/启动域时所输入的密码。如果更改了某个域的主密码,则必须执行相同的步骤在与此域关联的每个节点代理上更改此密码。

更改管理密码

管理密码安全性中介绍了如何对管理密码进行加密。强烈建议您对管理密码进行加密。如果要在加密管理密码之前更改管理密码,请使用 asadmin set 命令。用于此目的的 set 命令的示例如下:


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

还可以使用管理控制台更改管理密码,步骤如下。

要使用管理控制台更改管理密码,请选择“配置”节点 >“要配置的实例”>“安全性”节点 >“领域”节点 > admin-realm 节点,并根据需要编辑领域页面。

关于验证和授权

验证和授权是应用服务器安全性的核心概念。以下主题讨论了与验证和授权相关的内容:

验证实体

验证是一种实体(用户、应用程序或组件)用来确定另一个实体是否是其声明的实体的方法。实体使用安全凭证对其自身进行验证。凭证可以是一个用户名和密码、一个数字证书或其他凭证。

通常,验证表示用户使用用户名和密码登录到某个应用程序;也可以指 EJB 从服务器请求资源时,提供安全凭证。通常,服务器或应用程序要求客户机进行验证;另外,客户机也可以要求服务器对其自身进行验证。如果验证是双向的,则称为双向验证。

当实体尝试访问受保护的资源时,Application Server 将使用为该资源配置的验证机制来决定是否授予访问权限。例如,用户可以在 Web 浏览器中输入用户名和密码,如果应用程序顺利完成了对那些凭证的检验,则表示该用户已通过验证。在此会话余下的时间内,该用户将始终与这个经过验证的安全身份相关联。

Application Server 支持四种类型的验证,如验证实体所述。应用程序在其部署描述符中指定所使用的验证类型。有关使用 deploytool 来配置应用程序验证方法的更多信息,请参见位于以下 URL 的《The J2EE 1.4 Tutorial》:http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

表 9–1 Application Server 验证方法

验证方法

通信协议

说明

用户凭证加密

基本 

HTTP(SSL 可选) 

使用服务器的内置弹出式登录对话框。 

无,除非使用 SSL。 

基于表单 

HTTP(SSL 可选) 

应用程序提供它自己的自定义登录页面和错误页面。 

无,除非使用 SSL。 

客户机证书 

HTTPS(基于 SSL 的 HTTP) 

服务器使用公钥证书来验证客户机。 

SSL 

检验单点登录

单点登录允许一个虚拟服务器实例中的多个应用程序共享用户验证状态。使用单点登录,登录到一个应用程序的用户也会隐式登录到需要相同验证信息的其他应用程序。

单点登录以组为基础。其部署描述符定义了相同的并使用相同验证方法(基本、表单、摘要或证书)的所有 Web 应用程序共享单点登录。

对于为 Application Server 定义的虚拟服务器,默认情况下已启用单点登录。

对用户进行授权

用户通过验证后,授权级别将决定该用户可以执行哪些操作。用户的授权基于其角色。例如,人力资源应用程序可以授权管理者查看所有雇员的个人信息,但只允许雇员查看自己的个人信息。有关角色的更多信息,请参见了解用户、组、角色和区域

指定 JACC 提供者

JACC(Java 容器授权合同)属于 J2EE 1.4 规范,它为可插拔授权提供者定义了接口。这使得管理员可以设置第三方插件模块来执行授权。

默认情况下,Application Server 提供一个符合 JACC 规范的基于文件的简单授权引擎。还可以指定其他第三方 JACC 提供者。

JACC 提供者使用 Java 验证和授权服务 (JAAS) API。JAAS 允许服务验证并强制对用户进行访问控制。JAAS 实现了 Java 技术版本的标准可插拔验证模块 (PAM) 框架。

审计验证和授权决策

Application Server 可以通过审计模块提供对所有验证和授权决策的审计跟踪。Application Server 提供了一个默认的审计模块,还提供了自定义审计模块的功能。有关开发自定义审计模块的信息,请参见 Application Server Developer's Guide 中的 "Configuring an Audit Module" 一节。

配置消息安全性

消息安全性使服务器可以在消息层执行 Web 服务调用和响应的端对端验证。Application Server 使用 SOAP 层上的消息安全性提供者来实现消息安全性。消息安全性提供者提供了请求和响应消息所需的验证类型等信息。支持的验证类型包括:

该版本附带了两个消息安全性提供者。可以为 SOAP 层的验证配置消息安全性提供者。可以配置的提供者包括 ClientProviderServerProvider

对消息层安全性的支持以(可插入)验证模块的形式集成到 Application Server 及其客户机容器中。默认情况下,Application Server 中的消息层安全性处于禁用状态。

可以为整个 Application Server 或者为特定应用程序或方法配置消息层安全性。第 10 章,配置消息安全性介绍了如何配置 Application Server 级别的消息安全性。Developer's Guide"Securing Applications" 一章介绍了如何配置应用程序级别的消息安全性。

了解用户、组、角色和区域

Application Server 对以下实体强制执行其验证和授权策略:


注 –

尽管用户和组是为整个 Application Server 指定的,但是每个应用程序都需要定义自己的角色。当封装和部署应用程序时,应用程序会指定用户/组和角色之间的映射,如下图所示。


图 9–1 角色映射

该图显示了如何将用户指定到组中、如何将用户和组指定给角色以及应用程序如何使用组和角色。

用户

用户是已在 Application Server 中定义的单个(或应用程序)身份。用户可以与组关联。Application Server 验证服务可以管理多个领域中的用户。

J2EE 组(或简称组)是按常见特性(例如职务或用户配置文件)分类的用户类别。例如,假定电子商务应用程序的用户属于 customer 组,但是大客户可以属于 preferred 组。将用户分组可以简化对用户量很大时的访问控制。

角色

角色定义用户可以访问哪些应用程序和每个应用程序的哪些部分,并定义用户可以执行的操作。也就是说,角色决定用户的授权级别。

例如,假定在人事应用程序中,所有雇员均可以访问电话号码和电子邮件地址,但只有管理人员才能访问薪水信息。该应用程序至少需要定义两个角色:employeemanager;仅允许处于 manager 角色的用户查看薪水信息。

角色与用户组的不同之处在于,角色在应用程序中定义功能,而用户组是以某一方式相关的一组用户。例如,假定在人事应用程序中有 full-timepart-timeon-leave 几个组,但所有这些组中的用户仍是 employee 角色。

角色是在应用程序部署描述符中定义的。相反,组是针对整个服务器和区域而定义的。应用程序开发者或部署者在每个应用程序的部署描述符中将角色映射到一个或多个组。

区域

领域也称为安全策略域安全域,是服务器定义和强制执行通用安全策略的范围。在实际应用中,区域是服务器存储用户和组信息的系统信息库。

Application Server 预先配置了三个领域:file(初始默认领域)、certificateadmin-realm。还可以设置 ldapsolaris 或自定义领域。应用程序可以在其部署描述符中指定要使用的区域。如果应用程序不指定领域,Application Server 将使用其默认领域。

file 领域中,服务器将用户凭证存储在本地名为 keyfile 的文件中。您可以使用管理控制台来管理 file 领域中的用户。.

certificate 领域中,服务器将用户凭证存储在证书数据库中。使用 certificate 领域时,服务器结合使用证书和 HTTPS 协议来验证 Web 客户机。有关证书的更多信息,请参见证书和 SSL 简介

admin-realm 也是一个 FileRealm,它将管理员用户凭证存储在本地名为 admin-keyfile 的文件中。您可以使用管理控制台管理此领域中的用户,方法与管理 file 领域中的用户相同。

ldap 领域中,服务器将从轻量目录访问协议 (Lightweight Directory Access Protocol, LDAP) 服务器(例如 Sun Java System Directory Server)中获取用户凭证。LDAP 是一种协议,它使任何人都可以在网络(无论是公共 Internet 还是企业内联网)中查找组织、个人和其他资源(例如文件和设备)。有关管理 ldap 领域中的用户和组的信息,请参阅您的 LDAP 服务器文档。

solaris 领域中,服务器将从 Solaris 操作系统中获取用户凭证。Solaris 9 OS 和更高版本支持此区域。有关管理 solaris 领域中的用户和组的信息,请参阅您的 Solaris 文档。

自定义区域是用户凭证的任何其他系统信息库,例如关系型数据库或第三方组件。有关更多信息,请参见管理控制台联机帮助。

证书和 SSL 简介

本节包括以下主题:

关于数字证书

数字证书(或简称证书)是在 Internet 上唯一地标识人员和资源的电子文件。证书使两个实体之间能够进行安全、保密的通信。

证书有很多种类型,例如个人证书(由个人使用)和服务器证书(用于通过安全套接字层 [SSL] 技术在服务器和客户机之间建立安全会话)。有关 SSL 的更多信息,请参见关于安全套接字层

证书是基于公钥加密的,公钥加密使用数字密钥对(很长的数字)对信息进行加密或编码,从而使信息只能被目标收件人读取。然后,收件人对信息进行解密(解码)即可读取该信息。

一个密钥对包含一个公钥和一个私钥。拥有者对公钥进行分发并使任何人都可以使用该公钥。但是拥有者永远不会分发私钥;私钥始终是保密的。由于密钥与数学相关,因此使用了密钥对中的一个密钥进行加密的数据只能通过密钥对中的另一个密钥进行解密。

证书就好像一本护照:它可以标识持有者并提供其他重要信息。证书由称为证书授权机构 (Certification Authority, CA) 的可信赖第三方发布。CA 类似于护照申领办公室:它将验证证书持有者的身份并对证书进行签名,以使他人无法伪造或篡改证书。CA 对证书进行签名之后,持有者可以提供该证书作为身份证明并建立经过加密的保密通信。

最重要的是,证书会将拥有者的公钥绑定到拥有者的标识。与护照将照片绑定到其持有者的个人信息类似,证书将公钥绑定到有关其拥有者的信息。

除了公钥以外,证书通常还包括以下信息:

数字证书受 X.509 格式的技术规范约束。要检验 certificate 领域中某个用户的身份,验证服务将使用 X.509 证书的通用名称字段作为主体名称来检验 X.509 证书。

关于证书链

Web 浏览器已预先配置了一组浏览器自动信任的 CA 证书。来自其他证书授权机构的所有证书都必须附带证书链,以检验这些证书的有效性。证书链是由一系列 CA 证书发出的证书序列,最终以根 CA 证书结束。

证书最初生成时是一个自签名证书。自签名证书是其签发者(签名者)与主题(其公钥由该证书进行验证的实体)相同的证书。如果拥有者向 CA 发送证书签名请求 (CSR),然后输入响应,自签名证书将被证书链替换。链的底部是由 CA 发布的、用于验证主题的公钥的证书(回复)。链中的下一个证书是验证 CA 的公钥的证书。通常,这是一个自签名证书(即,来自 CA、用于验证其自身的公钥的证书)并且是链中的最后一个证书。

在其他情况下,CA 可能会返回一个证书链。在此情况下,链的底部证书是相同的(由 CA 签发的证书,用于验证密钥条目的公钥),但是链中的第二个证书是由其他 CA 签发的证书,用于验证您向其发送了 CSR 的 CA 的公钥。然后,链中的下一个证书是用于验证第二个 CA 的密钥的证书,依此类推,直至到达自签名的证书。因此,链中的每个证书(第一个证书之后的证书)都需要验证链中前一个证书的签名者的公钥。

关于安全套接字层

安全套接字层 (Secure Socket Layer, SSL) 是用来确保 Internet 通信和事务安全的最常见的标准。Web 应用程序使用 HTTPS(基于 SSL 的 HTTP),HTTPS 使用数字证书来确保在服务器和客户机之间进行安全、保密的通信。在 SSL 连接中,客户机和服务器在发送数据之前都要对数据进行加密,然后由收件人对其进行解密。

当 Web 浏览器(客户机)需要与某个安全站点建立连接时,则会发生 SSL 握手

握手之后,即表示客户机已检验了 Web 站点的身份,并且只有该客户机和 Web 服务器拥有会话密钥副本。从现在开始,客户机和服务器便可以使用该会话密钥对彼此间的所有通信进行加密。这样就确保了客户机和服务器之间的通信的安全性。

SSL 标准的最新版本称为 TLS(传输层安全性)。Application Server 支持安全套接字层 (Secure Socket Layer, SSL) 3.0 和传输层安全性 (Transport Layer Security, TLS) 1.0 加密协议。

要使用 SSL,Application Server 必须拥有接受安全连接的每个外部接口或 IP 地址的证书。只有安装了数字证书之后,大多数 Web 服务器的 HTTPS 服务才能够运行。使用使用 keytool 实用程序生成证书中介绍的过程来设置您的 Web 服务器可用于 SSL 的数字证书。

关于加密器

加密器是用于加密或解密的加密算法。SSL 和 TLS 协议支持用于服务器和客户机彼此进行验证、传输证书和建立会话密钥的各种加密器。

某些加密器比其他加密器更强大且更安全。客户机和服务器可以支持不同的密码组。从 SSL3 和 TLS 协议中选择加密器。在安全连接期间,客户机和服务器同意在通信中使用它们均已启用的最强大的加密器,因此通常需要启用所有加密器。

使用基于名称的虚拟主机

对安全应用程序使用基于名称的虚拟主机可能会带来问题。这是 SSL 协议本身的设计限制。必须先进行 SSL 握手(客户机浏览器在这时接受服务器证书),然后才能访问 HTTP 请求。这样,在验证之前就无法确定包含虚拟主机名的请求信息,因此也不能将多个证书指定给单个 IP 地址。

如果单个 IP 地址上的所有虚拟主机都需要通过同一证书的验证,则添加多个虚拟主机将不会影响服务器上正常的 SSL 操作。但是请注意,大多数浏览器会将服务器的域名与证书中列出的域名(如果有的话,也主要适用于官方的 CA 签名证书)进行比较。如果域名不匹配,这些浏览器将显示警告。通常在生产环境中,只将基于地址的虚拟主机与 SSL 一起使用。

关于防火墙

防火墙控制两个或多个网络之间的数据流,并管理网络之间的链接。防火墙可以包含硬件和软件元素。本节介绍了一些常用的防火墙体系结构及其配置。此处的信息主要是针对 Application Server 的。有关特定防火墙技术的详细信息,请参阅防火墙供应商提供的文档。

通常,需要对防火墙进行配置,以便客户机访问所需的 TCP/IP 端口。例如,如果 HTTP 侦听器正在端口 8080 上运行,则将防火墙配置为仅允许处理端口 8080 上的 HTTP 请求。同样地,如果为端口 8181 设置了 HTTPS 请求,则必须将防火墙配置为允许处理端口 8181 上的 HTTPS 请求。

如果需要通过 Internet 对 EJB 模块进行直接的 RMI-IIOP 访问,RMI-IIOP 全称为 Remote Method Invocations over Internet Inter-ORB Protocol(通过基于 Internet 的 ORB 间协议的远程方法调用),则还需要打开 RMI-IIOP 侦听器端口,但强烈建议您不要这样做,因为这样可能会破坏安全性。

在双防火墙体系结构中,您必须将外部防火墙配置为允许处理 HTTP 和 HTTPS 事务。您必须将内部防火墙配置为允许 HTTP 服务器插件与防火墙后面的 Application Server 进行通信。

使用管理控制台管理安全性

管理控制台提供了对安全性的以下方面进行管理的方法:

服务器安全性设置

在“安全性设置”页面中,设置整个服务器的属性,包括指定默认区域、匿名角色和默认的主体用户名和密码。

领域和 file 领域用户

了解用户、组、角色和区域中介绍了领域的概念。

JACC 提供者

指定 JACC 提供者中介绍了 JACC 提供者。使用管理控制台可以执行以下任务:

审计模块

审计验证和授权决策中介绍了审计模块。审计是记录重要事件(例如错误或安全漏洞)以便随后进行检查的方法。所有验证事件都被记录到 Application Server 日志中。完整的访问日志提供了 Application Server 访问事件的顺序线索。

使用管理控制台可以执行以下任务:

消息安全性

配置消息安全性中介绍了消息安全性的概念。使用管理控制台可以执行以下任务:

有关这些任务的详细信息,请参见管理控制台联机帮助。

HTTP 和 IIOP 侦听器安全性

HTTP 服务中的每个虚拟服务器都通过一个或多个 HTTP 侦听器提供网络连接。

Application Server 支持 CORBA(Common Object Request Broker Architecture,公共对象请求代理体系结构)对象,这类对象使用基于 Internet 对象请求代理间协议 (Internet Inter-Orb Protocol, IIOP) 在网络上进行通信。IIOP 侦听器接受来自 EJB 组件的远程客户机和其他基于 CORBA 的客户机的外来连接。有关 IIOP 侦听器的一般信息,请参见IIOP 侦听器

使用管理控制台可以执行以下任务:

管理服务安全性

管理服务确定服务器实例是一个常规实例、一个域管理服务器 (DAS) 还是一个组合。使用管理服务配置 JSR-160 兼容的远程 JMX 连接器,该连接器处理域管理服务器与用于远程服务器实例的节点代理(管理主机上的服务器实例)之间的通信。

使用管理控制台可以执行以下任务:

安全映射

使用管理控制台可以执行以下安全映射任务:

使用证书和 SSL

关于证书文件

安装 Application Server 时将生成一个适用于内部测试的 JSSE(Java Secure Socket Extension,Java 安全套接口扩展)或 NSS(Network Security Service,网络安全服务)格式的数字证书。默认情况下,Application Server 将其证书信息存储在 domain-dir/config 目录下的证书数据库中:

更改证书文件的位置

为开发提供的密钥库和信任库文件存储在 domain-dir/config 目录中。

使用管理控制台依次展开 server-config 节点 >“JVM 设置”>“JVM 选项”选项卡,可以添加或修改证书文件新位置的值字段。


-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/NSS-database-directory

其中,NSS-database-directory 是 NSS 数据库的位置。

使用 Java 安全套接口扩展 (Java Secure Socket Extension, JSSE) 工具

使用 keytool 可以设置和使用 JSSE(Java Secure Socket Extension,Java 安全套接口扩展)数字证书。在 Platform Edition 和 Enterprise Edition 中,客户机端(应用程序客户机端或独立客户机端)均使用 JSSE 格式。

J2SE SDK 附带了 keytool,管理员可以使用它来管理公钥/私钥对和关联证书。还允许用户高速缓存正与其通信的另一方的公钥(以证书形式)。

要运行 keytool,必须先配置 shell 环境以使 J2SE /bin 目录位于路径中;或者必须在命令行中提供此工具的完整路径。有关 keytool 的更多信息,请参见 http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html 上的 keytool 文档。

使用 keytool 实用程序

以下示例说明了使用 JSSE 工具处理证书的相关用法:

使用 keytool 实用程序生成证书

使用 keytool 可以生成、导入和导出证书。默认情况下,keytool 将在其运行所在的目录中创建一个密钥库文件。

  1. 转至要运行证书的目录。

    始终在包含密钥库和信任库文件的目录中生成证书,默认目录为 domain-dir/config。有关更改这些文件位置的信息,请参见更改证书文件的位置

  2. 输入以下 keytool 命令以在密钥库文件 keystore.jks 中生成证书:


    keytool -genkey -alias keyAlias-keyalg RSA
     -keypass changeit
     -storepass changeit
    -keystore keystore.jks

    使用任一唯一的名称作为您的 keyAlias。如果您已更改密钥库或私钥密码的默认值,请将以上命令中的 changeit 替换为新密码。

    将显示一个要求您输入姓名、组织和其他信息的提示,keytool 将使用这些信息来生成证书。

  3. 输入以下 keytool 命令以将生成的证书导出到文件 server.cer(或 client.cer,如果您愿意):


    keytool -export -alias keyAlias-storepass changeit
     -file server.cer
     -keystore keystore.jks
  4. 如果要求证书授权机构签名的证书,请参见使用 keytool 实用程序为数字证书签名

  5. 要创建信任库文件 cacerts.jks 并将证书添加到信任库中,请输入以下 keytool 命令:


    keytool -import -v -trustcacerts
    -alias keyAlias
     -file server.cer
    -keystore cacerts.jks
     -keypass changeit
  6. 如果您已更改密钥库或私钥密码的默认值,请将以上命令中的 changeit 替换为新密码。

    工具将显示有关证书的信息并提示您是否要信任该证书。

  7. 键入 yes,然后按 Enter 键。

    然后,keytool 将显示与下面类似的信息:


    Certificate was added to keystore
    [Saving cacerts.jks]
  8. 重新启动 Application Server。

使用 keytool 实用程序为数字证书签名

创建数字证书之后,拥有者必须为其签名以防止伪造。电子商务站点或身份验证对其很重要的那些站点可以从知名的证书授权机构 (CA) 购买证书。如果无需考虑验证,例如当专用安全通信可以满足全部需求时,则可节省获取 CA 证书所花费的时间和费用并使用自签名证书。

  1. 按照 CA Web 站点上的说明进行操作来生成证书密钥对。

  2. 下载生成的证书密钥对。

    将证书保存在包含密钥库和信任库文件的目录中,默认目录为 domain-dir/config。请参见更改证书文件的位置

  3. 在 shell 中,转至包含证书的目录。

  4. 使用 keytool 将证书导入到本地密钥库和本地信任库(如有必要)。


    keytool -import -v -trustcacerts
    -alias keyAlias
     -file server.cer
    -keystore cacerts.jks
     -keypass changeit
    -storepass changeit

    如果密钥库或私钥密码不是默认密码,请将以上命令中的 changeit 替换为新密码。

  5. 重新启动 Application Server。

使用 keytool 实用程序删除证书

要删除现有证书,请使用 keytool -delete 命令,例如:

keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password

使用网络安全服务 (NSS) 工具

在 Enterprise Edition 中,在服务器端使用网络安全服务 (Network Security Service, NSS) 数字证书可以管理存储私钥和证书的数据库。对于客户机端(应用程序客户机端或独立客户机端),均使用使用 Java 安全套接口扩展 (Java Secure Socket Extension, JSSE) 工具中介绍的 JSSE 格式。

通过网络安全服务 (NSS) 管理安全性的工具包括:

这些工具位于 install-dir/lib/ 目录中。下面的环境变量用于指出 NSS 安全性工具的位置:

在示例中,证书通用名 (Common Name, CN) 是客户机或服务器的名称。在 SSL 握手时也会使用 CN,以比较证书名称和生成证书名的主机名。如果证书名称与主机名不匹配,在 SSL 握手时会产生警告或异常。在某些示例中,使用证书通用名 CN=localhost 是为了方便起见,这样所有用户都可以使用该证书,而不必用他们自己的真实主机名创建一个新证书。

以下各节中的示例说明使用 NSS 工具处理证书的相关用法:

使用 certutil 实用程序

在运行 certutil 之前,请确保 LD_LIBRARY_PATH 指向运行此实用程序所需的库的位置。此位置可以通过 asenv.conf(产品范围的配置文件)中 AS_NSS_LIB 的值来标识。

证书数据库工具 certutil 是一个 NSS 命令行实用程序,可以创建和修改 Netscape Communicator cert8.dbkey3.db 数据库文件。还可以列出、生成、修改或删除 cert8.db 文件中的证书,以及创建或更改密码、生成新的公钥和私钥对、显示密钥数据库的内容或删除 key3.db 文件中的密钥对。

密钥和证书管理进程通常以在密钥数据库中创建密钥开始,然后在证书数据库中生成和管理证书。位于以下网址的文档说明了使用 NSS(包括 certutil 实用程序的语法)管理证书和密钥数据库:http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html

下表中的每一项都给出了一个使用 NSS 和 JSSE 安全性工具来创建和/或管理证书的示例。

使用 pk12util 实用程序导入和导出证书

pk12util 是一个命令行实用程序,用于以 PKCS12 格式在证书/密钥数据库和文件之间导入和导出密钥和证书。PKCS12 是公钥加密标准 (Public-Key Cryptography Standards, PKCS) #12 个人信息交换语法标准。有关 pk12util 实用程序的更多说明,请参见 http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html

使用 modutil 添加和删除 PKCS11 模块

安全性模块数据库工具 modutil 是一个命令行实用程序,用于管理 secmod.db 文件中或硬件令牌中的 PKCS #11(Cryptographic Token Interface Standard,加密令牌接口标准)模块信息。您可以使用此工具添加和删除 PKCS #11 模块、更改密码、设置默认值、列出模块内容、启用或禁用插槽、启用或禁用 FIPS-140-1 兼容性以及指定加密操作的默认提供者。此工具还可以创建 key3.dbcert7.dbsecmod.db 安全性数据库文件。有关此工具的更多信息,请参见 http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html

对 Application Server 使用硬件加密加速器

您可以使用硬件加速器令牌来提高加密性能并提供安全密钥存储功能。此外,还可以通过智能卡为最终用户提供移动安全密钥存储。

当 Sun Java System Application Server 8.1 和 8.2 Standard Edition 或 Enterprise Edition 在 Java 2 Platform, Standard Edition(J2SE 平台)5.0 上运行时,支持针对 SSL 或 TLS 通信使用 PKCS#11 令牌,以及使用网络安全服务 (Network Security Service, NSS) 工具来管理密钥和 PKCS#11 令牌。本节介绍 Application Server 如何提供此支持,并指导您完成相关配置的过程。

J2SE 5.0 PKCS#11 提供者可以轻松与 Application Server 运行时集成。通过这些提供者,您可以使用硬件加速器以及 Application Server 中的其他 PKCS#11 令牌来提高性能,并保护 SSL 或 TLS 通信中固有的私钥。

本节包括以下主题:

关于配置硬件加密加速器

Sun Java System Application Server 8.1 和 8.2 Standard Edition 或 Enterprise Edition 已针对 Sun Crypto Accelerator 1000 (SCA-1000) 和 SCA-4000 进行了测试。

Application Server 与 J2SE 5.0 结合使用时,可以与 PKCS#11 令牌进行通信。Application Server 附带有 NSS PKCS#11 令牌库(对于 NSS 内部 PKCS#11 模块,通常称为 NSS 软令牌)和 NSS 命令行管理工具。有关更多详细信息,请参见使用网络安全服务 (NSS) 工具

使用 NSS 工具可以在 PKCS#11 令牌中创建密钥和证书,使用 J2SE PKCS#11 提供者可以在运行时访问令牌密钥和证书。PKCS#11 提供者是用作本地 PKCS#11 库包装器的加密服务提供者。PKCS#11 令牌通常是指所有具有本地 PKCS#11 接口的硬件令牌和软件令牌。硬件令牌是指以物理设备(例如硬件加速器及智能卡)实现的 PKCS#11 令牌。软件令牌是指完全以软件实现的 PKCS#11 令牌。


注 –

如果在 J2SE 1.4.x 平台上运行 Application Server,则仅支持一种 PKCS#11 令牌,即 NSS 软令牌。


对于 Microsoft Windows 环境,将 NSS 库的位置 AS_NSS 以及 NSS 工具目录 AS_NSS_BIN 添加到 PATH 环境变量中。为简单起见,本节中所述的过程仅使用 UNIX 命令。您应在适当的情况下将 UNIX 变量替换为 Windows 变量。

配置硬件加密加速器包括两个主要过程:

配置 PKCS#11 令牌

本节介绍如何使用 NSS 安全性工具 modutil 来配置 PKCS#11 令牌。可以使用以下过程配置 PKCS#11 令牌。

输入以下命令(在一行中输入全部内容):

modutil -dbdir AS_NSS_DB -nocertdb -force -add moduleName -libfile
 absolute_path_of_pkcs11_library -mechanisms list_of_security_mechanisms

其中,AS_NSS_DB 是 NSS 数据库目录(如同使用域管理服务器 (Domain Administration Server, DAS) 时的 AS_DOMAIN_CONFIG

例如,要配置硬件加速器令牌,请输入以下命令(在一行中输入全部内容):

modutil -dbdir AS_NSS_DB -nocertdb -force -add "Sun Crypto Accelerator" -libfile
 /opt/SUNWconn/crypto/lib/libpkcs11.so -mechanisms RSA:DSA:RC4:DES

在本例中,硬件加速器为 SCA–1000 加密加速器。默认情况下,相应的 PKCS#11 库位于 /opt/SUNWconn/crypto/lib/libpkcs11.so 中。

mechanisms 必须是可用于令牌中的加密机制的完整列表。要仅使用少数可用的加密机制,请参见配置 J2SE 5.0 PKCS#11 提供者。有关所有支持的机制的列表,请参见 NSS Security Tools 站点 http://www.mozilla.org/projects/security/pki/nss/tools 上的 modutil 文档。

下面的示例假设在安装令牌时指定的令牌名称为 mytoken

要检验硬件加速器配置是否正确,请输入以下命令:

modutil -list -dbdir AS_NSS_DB

标准输出类似于以下内容:


Using database directory /var/opt/SUNWappserver/domains/domain1/config ...

Listing of PKCS#11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS#11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services                            
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services                  
        token: NSS Certificate DB

  2. Sun Crypto Accelerator
        library name: /opt/SUNWconn/crypto/lib/libpkcs11.so
         slots: 1 slot attached
        status: loaded

         slot: Sun Crypto Accelerator:mytoken
        token: mytoken
-----------------------------------------------------------

 

管理密钥和证书

本节介绍几个使用 certutilpk12util 创建和管理密钥和证书的常用过程。有关certutilpk12util 的详细信息,请参见使用网络安全服务 (NSS) 工具以及 NSS Security Tools 站点 http://www.mozilla.org/projects/security/pki/nss/tools 上的文档。


注 –

通过在 java.security 属性文件(位于 Java 运行时的 JAVA_HOME/jre/lib/security 目录中)中配置 PKCS#11 提供者,您还可以使用 J2SE keytool 实用程序来管理密钥和证书。有关使用 keytool 的详细信息,请参见位于 http://java.sun.com/j2se/1.5.0/docs/guide/secuirty/p11guide.html 的《Java PKCS#11 Reference Guide》。


本节包括以下数个主题:

列出密钥和证书

使用私钥和证书

可以使用 certutil 创建自签名证书以及导入或导出证书。要导入或导出私钥,请使用 pk12util 实用程序。有关更多详细信息,请参见使用网络安全服务 (NSS) 工具


注意 – 注意 –

在 Application Server 中,请勿直接使用 NSS 工具 certutilmodutil 修改 NSS 密码。如果这样做,Application Server 中的安全性数据可能会被破坏。


配置 J2SE 5.0 PKCS#11 提供者

Application Server 依靠 J2SE PKCS#11 提供者在运行时访问位于 PKCS#11 令牌中的密钥和证书。默认情况下,Application Server 将针对 NSS 软令牌来配置 J2SE PKCS#11 提供者。本节介绍如何覆盖 J2SE PKCS#11 提供者的默认配置。

在 Application Server 中,将针对每个 PKCS#11 令牌生成以下默认 PKCS#11 配置参数。

这些配置符合《Java PKCS#11 Reference Guide》中所述的语法。


注 –

除了必须唯一之外,对名称参数没有任何要求。某些早期版本的 J2SE 5.0 仅支持字母数字字符。


您可以通过创建自定义配置文件来覆盖默认配置参数。例如,可以在 SCA–1000 中明确禁用 RSA 加密器和 RSA 密钥对生成器。有关禁用 RSA 加密器和 RSA 密钥对生成器的详细信息,请参见 http://www.mozilla.org/projects/security/pki/nss/tools

要创建自定义配置文件,请执行以下操作:

  1. 使用以下代码创建名为 install-dir/mypkcs11.cfg 的配置文件并保存此文件。


    name=HW1000
    library=/opt/SUNWconn/crypto/lib/libpkcs11.so
    slotListIndex=0
    disabledMechanisms = {
    	CKM_RSA_PKCS
    	CKM_RSA_PKCS_KEY_PAIR_GEN
    }
    omitInitialize=true
  2. 如果有必要,请更新 NSS 数据库。在这种情况下,更新 NSS 数据库以便它禁用 RSA。

    运行以下命令:


    modutil -undefault "Sun Crypto Accelerator" -dbdir AS_NSS_DB -mechanisms RSA

    mechanisms 列表中的算法名称与默认配置中的算法名称不同。有关 NSS 中有效 mechanisms 的列表,请参见 NSS 安全性工具站点 http://www.mozilla.org/projects/security/pki/nss/tools 上的 modutil 文档。

  3. 通过在适当位置添加属性使用该更改来更新服务器,如下所示:


    <property name="mytoken" value="&InstallDir;/mypkcs11.cfg"/>

    此属性的位置可以为以下位置之一:

    • 如果提供者用于 DAS 或服务器实例,请在相关的 <security-service> 下添加此属性。

    • 如果提供者用于节点代理,请在 domain.xml 文件中相关的 <node-agent> 元素下添加此属性。

  4. 重新启动 Application Server。

    自定义配置将在重新启动后生效。

更多信息