Certificate lookup and validation

[0001] This application claims priority to U.S. Provisional Application No. 60/573,276 entitled “Certificate Lookup and Validation” filed May 21, 2004.

[0002] Public key infrastructure (PKI) supports a number of security measures including data security, company confidentiality, and entity authentication. The PKI services relate to the proper use of public/private key pairs. The Public component of the key pair is issued in the form of a public key certificate and associated with appropriate to cryptographic algorithms is used to verify digital signature, encrypt data or the like.

[0003] Before a certificate can be used, it must be validated. In order to validate a certificate, a chain of certificates or certification path between the certificate and an established point of trust must be established, and every certificate in the path must be checked. This process is referred to as certification path processing.

[0004] Certification path processing includes path construction or certificate lookup, and path validation. Path construction includes building one or more candidate certification paths. Path validation includes making sure that each certificate in the path is within the established validity period, hasn't been revoked and has integrity. An example of a certificate chain is the X.509 certificate chain. Typically, the certificate chain includes a root certificate signed by itself, the next certificate signed by the root certificate and so on until the final certificate signed by the next to the last certificate.

[0005] A Java Application Programming Interface (API) for implementing lookup and validation of X.509 certificate chains is the CertPath API which is a part of the Java Development Kit (JDK) available from Sun Microsystems of Santa Clara, Calif.

[0008] FIG. 1 shows a certificate validation framework 100. The certificate validation framework 100, in one embodiment, can allow client software, such as a client software 102 to do a certificate lookup and validation. In one embodiment, the certificate validation framework 100 does not require the client software 102 to provide plugin specific configuration data such as server location information ( i.e. for the additional servers 105). The JDK/API for a certificate path builder requires plugin specific information, such as the locations of the server including an XML Key Management Specification (XKMS) server or a Uniform Resource Locator (URL) for a Lightweight Directory Access Protocol (LDAP) server host and port network. The certificate validation framework 100 can store plugin specific configuration data in memory 104.

[0009] In one embodiment, the certificate validation framework 100 includes a client software interface 100a for receiving a request from the framework 100 can interact with a lookup or validation plug-in 106, which includes a plug-in interface 106a. In one embodiment, the certificate validation framework 100 interacts with a lookup or validation plug-in 106 to do the certificate lookup or validation. The plug-ins can also be called providers. The certificate validation framework 100 can provide information from the client software 102 as well as the stored plugin specific configuration data from the memory 104 to the lookup or validation plug-in 106. By using plug-ins to connect to the certificate validation framework, the client software 102 can be isolated from certain information such as the server location information. The plug-in 106 can define the plug-in interface 106a with respect to the certificate validation framework 100 to indicate the required information. In one embodiment, the plug-in interface includes the transfer of a management object, such as an MBean, from the plug-in 106 to indicate the information required by the lookup or validation plug-in 106. This information can be stored in the memory 104.

[0010] The MBean can indicate stored plugin specific configuration data such as server location. The plugin specific configuration data such as server location can be provided by the plug-ins supplied by the validation framework or input by a user or administrator.

[0011] In one embodiment, the configuration file 104b holds a plugin specific MBean which refers to configuration data 104a. At runtime, the plugin 106 can use the plugin specific MBean 104b to retrieve its configuration data 104a.

[0012] In one embodiment, the certificate validation framework 100 can be part of a server product, such as the WebLogic Server™ of BEA Systems, Inc., of San Jose, Calif.

[0013] In one embodiment, the plug-in 106 is a certificate path builder plug-in or a certificate path validator plug-in. In one embodiment, both a certificate path builder plug-in and certificate path validator plug-in can be connected to the certificate validation framework 100. The client software 102 can be, but is not limited to, a web server client certificate validation program, a secure socket layer (SSL) certificate validation program or application code.

[0014] In one embodiment, an MBean stores the plugin specific configuration data in a configuration file in the memory 104 of the system. In that way, the certificate validation framework 100 can isolate the client software 102 from needing to provide certain configuration information, such as such as server location information. The configuration information which can be provided by the plug-ins, set as a default by the validation framework 100 or input by user through an administration console 110. The plug-in interface 106a for the runtime can be defined with a management object such as an MBean, which indicates which information is required. For example, the MBean can indicate an LDAP server URL or an XKMS server location.

[0015] A CLV certpath model has a number of advantages over the over the JDK certpath model. The CLV model can move the responsibility for selecting the lookup and validation “quality of service” (ie. which plugins to use) and specifying the plugins' configuration data (e.g. XKMS server's host & port) from the client to the administrator. In one embodiment the JDK certpath and CLV certpath models are:

JDK model

[0016] plugin writer

• • [0017] by nature, the plugin has a certain “quality of service”
    • [0018] e.g. looks up & validates cert paths by using an XKMS server
  • [0019] configuration data
    • [0020] defines what configuration data it requires
      • [0021] e.g. XKMS server host & port
    • [0022] typically, the plugin defines a plugin-specific proprietary client configuration API
  • [0023] lookup & validation criteria
    • [0024] defines what criteria it supports for locating & validating cert paths
      • [0025] e.g. find cert path given the end certificdate's subject dn
    • [0026] defines the api for specifing the criteria
      • [0027] e.g. uses a standard JDK client certpath api (e.g. X509CertSelector)
      • [0028] e.g. defines a plugin specific proprietary client API
  • [0029] implements the JDK certpath SPIs

[0030] administrator

• • [0031] plugin installation
    • [0032] installs the plugin's code on the machine
  • [0033] quality of service
    • [0034] the administrator does not decide the quality of service (ie. which plugins to use).
      • [0035] instead, each client must decide the quality of service
  • [0036] plugin configuration
    • [0037] the adminstrator does not configure the plugins' configuration data (e.g. XKMS server host & port).
      • [0038] instead, each client must store the plugins' configuration data

[0039] client

• • [0040] quality of service
    • [0041] chooses which of the available plugins to use—ie. chooses lookup & validation quality of service
      • [0042] v.s. the administrator setting up one set of lookup & validation rules for all client
  • [0043] plugin configuration
    • [0044] the client must be aware of the plugin's configuration strategy
    • [0045] typically the client must persistently store the plugin's configuration data (e.g. XKMS server & port)
      • [0046] vs. the adminstrator configuring the plugins' configuration data once
    • [0047] typically the client must use the plugin's proprietary configuration API
  • [0048] lookup & validation criteria
    • [0049] the client must be aware of the plugin's lookup & validation criteria strategy
    • [0050] the client may be required to use a JDK api to specify the criteria (e.g. X509CertPathSelector)
    • [0051] the client may be required to the the plugin's proprietary lookup & validation criteria api
  • [0052] must be re-coded to take advantage of new plugin implementations
  • [0053] uses JDK certpath and plugin specific proprietary apis
    CLV model

[0054] plugin writer

• • [0055] by nature, the plugin has a certain “quality of service”
    • [0056] e.g. looks up & validates cert paths by using an XKMS server
  • [0057] configuration data
    • [0058] defines what configuration data it requires
      • [0059] e.g. XKMS server host & port
    • [0060] using WLS tools, defines a proprietary MBean api for specifying its configuration data
  • [0061] lookup & validation criteria
    • [0062] decides which of the WLS defined standard criteria for locating and validating cert paths it supports
      • [0063] e.g. find cert path given the end certificdate's subject dn
  • [0064] implements the JDK certpath SPIs AND the WLS CLV SPIs
  • [0065] symmetrical with writing other WLS security plugins (e.g. for authentication/authorization)

[0066] administrator

• • [0067] plugin installation
    • [0068] installs the plugin's code on the machines, using WLS mechanisms
  • [0069] quality of service
    • [0070] chooses which of the available plugins to use—the lookup & validation quality of service
    • [0071] this qualify of service is used for all clients
      • [0072] v.s. each client selecting the quality of service
    • [0073] typically uses the WLS admin console to choose which plugins to use
  • [0074] plugin configuration
    • [0075] configures the plugins' configuration data (e.g. XKMS server's host & port)
    • [0076] this configuration is used for all clients
      • [0077] vs. each client storing the plugins' configuration data
    • [0078] typically uses the WLS admin console to configure the plugins' persistent data
      • [0079] automatically get console pages taylored to the plugin's required persistent data
        • [0080] e.g. fields to enter the XKMS server's host & port
        • [0081] generated from the plugin's configuration mbean api
    • [0082] WLS CLV framework persistently stores this configuration data on behalf of the configured plugins
      • [0083] sends this configuration data to the plugins at runtime
        • [0084] via each plugin's configuration mbean api
      • [0085] relieves the plugins from having to persist their configuration data
  • [0086] symmetrical with administering other WLS security plugins (e.g. for authentication/authorization)

[0087] client

• • [0088] quality of service
    • [0089] does not choose which plugins to use
      • [0090] the administrator does this instead
  • [0091] plugin configuration
    • [0092] does not configure the plugins' configuration data (e.g. XKMS server & port)
      • [0093] the administrator does this instead
  • [0094] lookup & validation criteria
    • [0095] decides which of the WLS defined standard criteria for locating and validating cert paths it requires
      • [0096] e.g. find cert path given the end certificdate's subject dn
  • [0097] uses WLS & JDK certpath apis
    • [0098] never uses plugin specific proprietary apis
  • [0099] new plugin implementations can be installed and configured by the administrator
    • [0100] don't need to reconfigure or recode clients

[0101] In one embodiment:

• • [0102] the plugin writer decides what configuration data it requires (e.g. XKMS server's host & port)
  • [0103] the plugin writer can write a configuration mBean API for getting and setting those fields.
  • [0104] the WLS console create customized pages for that plugin based on its mBean API (ie. fields for specifying the XKMS server's host & port)
  • [0105] the administrator uses these console pages to enter the plugin's configuration data (e.g. the administrator specifies the XKMS server's host & port)
  • [0106] WLS persists this data to a configuration file. The format of the file is based on the plugin's mBean API
  • [0107] WLS makes the configuration data available to the plugin via the plugin's mBean API.

[0108] The following implementation is given as a non-limiting example.

Example Implementation

[0109] This is a description of details of a certificate lookup and validation framework of one embodiment.

[0110] FIG. 2 is an example that shows a certificate lookup and validation framework 200 which is a security plug-in framework that finds and validates certificate chains such as X.509 certificate chains. It provides an API and SPI which extends JDK's CertPath API/SPI.

[0111] The framework 200 provides a security service for certificate validation and lookup for 2-way SSL or WebServices. This service consists of a simple API and is used from components that need to validate or lookup certificates (e.g., 2 way SSL).

The Certificate Lookup and Validation (CLV) framework 200 can satisfy the following consumers:

[0112] A client sends a method request to a WebService. It may sign parts of the request. If it does, the client should include its signing certificate's chain, its signing certificate or a reference to its signing certificate (e.g. subject Distinction Name (DN) in the request. Similarly, if the client wants the response to be encrypted, it includes its encryption certificate, chain or reference in the request.

[0113] Web Services can use a CLV API that validates a chain. It also can use an API that, given the certificate, or reference to the certificate, and returns a validated certificate chain.

[0114] The current draft of the OASIS WebServices security specification allows for three types of certificate references: subject DN, issuer DN plus serial number, and subject key identifier which are supported by the CLV API. The CLV framework can support other forms of certificate references. The Extensible Markup Language (XML) digital signature specification says that the client may pass a reference to its certificate so this can be supported as well.

[0115] Outbound SSL 204 and 2-way inbound Secure Sockets Layer (SSL) can receive certificate chains during the SSL handshake. The chains are either complete, or may be missing the root Certification Authority (CA) that terminates the chain.

[0116] An example of 2-way inbound SSL is a browser connecting to a webapp over the HyperText Transfer Portocol Secure (HTTPS) where the browser sends the client's certificate chain to the webapp. An example of outbound SSL is an admin server talking to the node manager over an SSL connection.

[0117] SSL contains built-in code that, given a set of trusted CAs, completes and validates the chain. Customers can perform additional validation on the chain (e.g. for revocation checking). To accomplish this, SSL can use a CLV API that takes the completed and validated chain and performs extra validation.

[0118] In one embodiment, instead of removing all built-in validation from SSL and changing SSL to rely solely on the CLV framework for validation, SSL will continue to have built-in validation and will only use the CLV framework to perform extra validation (e.g. revocation checking).

[0119] Application code 206 in the server is allowed to use the CLV API directly to lookup and/or validate certificate chains.

Lookup and Validation Security Plug-in Providers:

[0120] The CLV framework provides a certificate lookup and validation plug-in SPI to allow customers and Independent Software Vendors (ISV)s to write their own lookup and validation security providers.

[0121] In one embodiment, there are two types of CLV security providers (thus two SPIs). The first, a “CertPathBuilder”, receives a certificate or certificate reference. It looks up or completes the certificate chain (if necessary) and validates it (e.g. a builder that uses an external XKMS server to lookup and validate the certificate chain).

[0122] The second, a “CertPathValidator”, receives a certificate chain (e.g. from a CertPathBuilder or from SSL) and performs extra validation (e.g. a validator that uses CRLs stored in an external LDAP server to perform revocation checking).

[0123] The CLV plug-in SPI can be symmetrical with the SPI for other security provider types (e.g. Authorizers). It can allow the plug-in to have custom configuration parameters (e.g. the URL of an external XKMS server), as well as custom console pages and management operations (e.g. to manage a certificate registry).

[0124] The administrator can configure the CLV providers for a security realm using MBeans and an administration console for server software, such as the administration console of WebLogic Server™ available from BEA Systems, Inc. of San Jose Calif.

[0125] In one embodiment, a security realm has one CertPathBuilder and zero or more CertPathValidators configured.

[0126] The CLV framework can provide two public APIs as client software interfaces. The first receives a certificate or certificate reference, uses the configured CertPathBuilder plug-in to lookup and validate the corresponding certificate chain, then uses the configured CertPathValidator plug-ins to perform extra validation. WebServices, Integration software, such as the WebLogic Integration™ available from BEA Systems, Inc., of San Jose, Calif., and Portal Software, such as WebLogic Portal™ available form BEA Systems, Inc., of San Jose, Calif., can use this API. It may also be used by application code.

[0127] The second public API, based on the JDK CertPathValidator API, receives a certificate chain then uses the configured CertPathValidator plug-ins to validate the chain. SSL, WebServices, and products such as Integration software and Portal software can use this API. It may also be used by application code (e.g., application supplied SSL trust managers).

[0128] The CLV framework supplies an API that SSL, WebServices, Integrated Software, Portal Software and application code may use to lookup and validate X.509 certificate chains. This API can hide the details of the CertPathBuilders and CertPathValidators the administrator has configured.

[0129] Since the JDK provides a CertPathBuilder API for looking up certificate chains and a CertPathValidator API for validating certificate chains, the CLV framework can use these JDK APIs instead of inventing its own API.

[0130] The JDK CertPath API/SPIs do not standardize the lookup criteria for finding certification chains or the types of certificate supported or how CertPath providers get their configuration data. Therefore, the CLV framework can extend the JDK CertPath API to provide a complete lookup and validation API.

CertPathBuilder API

[0131] This API is used to lookup and validate a certificate chain. WebServices can use this API to lookup and validate client certificates.

[0132] The API can have the following input parameters:

• • [0133] The name of the security realm
  • [0134] A CertPathSelector to indicate the desired certificate chain.
  • [0135] An optional ContextHandler that may be used to pass additional information to the CertPathBuilder and CertPathValidators configured for the security realm. This is symmetrical with the context handlers passed into other types of security providers.
  • [0136] An optional list of trusted CAs. Many CertPathBuilder and CertPathValidator providers require a list of trusted CAs (e.g. the JDK's PKIXCertPathBuilder). This allows the caller to indicate which trusted CAs should be used if trusted CAs are required. If not specified, then the default set of trusted CAs for the server will be used.

[0137] The API can support looking up a chain from the end certificate, or from the end certificate's subject DN, from the end certificate's issuer DN and serial number, from the end certificate's subject key identifier.

[0138] The API can return a chain of X.509 certificates. If the chain cannot be found or if it is not valid, then the API can throw an exception indicating the problem.

[0139] The framework uses the configured CertPathBuilder security provider to lookup and validate the chain. If found and valid, the framework then can call each configured CertPathValidator, in the order the administrator configured them, to perform extra validation on the chain. In one embodiment, the chain is only valid if the builder and all the validators successfully validate it.

[0140] The builder decides how much of the chain to return. It should at least include the chain's end certificate. For example, an XKMS CertPathProvider will return the entire chain, while the out of the box certificate registry, which allows the administrator to configure the list of valid end certificates, only returns the end certificate. This was done to fulfill a WebService requirement that the administrator be able to configure a server product, such as WebLogic Server™, to only validate that the end certificate is registered, without needing to configure all the issuer certificate authorities.

[0141] The builder also decides which types of lookup it supports. For example, the WebLogicCertPathProvider, which is based on the Certicom SSL certificate validation code, supports lookup from an end certificate but does not support lookup from a subject DN. The administrator should ensure that the configured builder supports the lookups that applications require.

[0142] In one embodiment, the API does not provide a standard mechanism for the caller to pass in additional validation criteria such as when it wants the chain to be valid or the key usage (e.g. the caller only wants WLS digital signature certificates). This was done to be symmetrical with the XKMS standard, which doesn't allow such criteria. The caller may use the X.509 Certificate API to perform these checks instead.

[0143] The API allows the caller to pass in context information. The context is passed to the builder and validators. This allows the caller and specific providers to agree on a set of extra parameters that might affect building or validation.

[0144] If a validator checks for expired certificates, it does so based on the current time (i.e. “now”). The caller may use the JDK X509Certificate API to perform extra time checking (for example, I need the certificate to be valid between Jul. 26, 2004 and Jul. 27, 2004)

[0145] A certificate issuer may include a key usage in the X509 certificate to indicate what the end certificate may be used for (e.g. DigSig signatures, DigSig encryption). The caller may use the JDK X509Certificate API to find the end certificate's key usage.

CertPathValidator API

[0146] This API is used to perform extra validation on a certificate chain. SSL, which has built-in code to complete and validate certificate chains, will use this API to perform extra validation (e.g. revocation checking) on the chain.

[0147] The API has the following input parameters:

• • [0148] The name of the security realm.
  • [0149] The X509 certificate chain to be validated
  • [0150] An optional ContextHandler that may be used to pass additional information to the CertPathValidatorProviders configured for the security realm. This is symmetrical with the context handles passed into other types of security providers.
  • [0151] An optional list of trusted CAs. Many CertPathValidator providers require a list of trusted CAs (e.g. the JDK's PKIXCertPathValidator). This allows the caller to indicate which trusted CAs should be used if trusted CAs are required. If not specified, then the default set of trusted CAs for the server will be used.

[0152] If the chain is valid, then the API just returns. If the chain is invalid, then the API throws an exception indicating the problem.

[0153] The framework performs the validation by calling each CertPathValidator security provider that the administrator configured. The validators are called in the order they are configured in the console. The certificate chain is valid if all the validators successfully validate it. Otherwise, it passes the first validation error back to the caller.

[0154] Like the CertPathBuilder API, this API does not provide a standard mechanism for the caller to pass in additional validation criteria other than a context. Again, the caller may use the JDK's X509Certificate API on the validated chain to perform extra validation. Or, the caller and the providers can agree on more specific validation parameters that will be passed via the context.

[0155] Note that SSL always performs some built-in validation before it calls this API to perform extra validation (e.g. revocation checking). SSL adds parameters to the context to indicate what validation it has already done. A CertPathValidator may use these parameters to avoid performing duplicate validation.

Certificate Lookup and Validation SPI

[0156] Customers and vendors can use this SPI and to write their own certificate lookup and validation security providers.

[0157] There are two types of providers: CertPathBuilders, which lookup and validate certificate chains, and CertPathValidators, which perform extra validation on a certificate chain.

[0158] The SPI is symmetrical with other security provider SPIs. It has three parts—an MBean SPI, a security provider SPI and a lookup/validation SPI.

[0159] The provider uses the MBean SPI to write a custom MBean. This MBean is used to configure WLS to use the provider. The MBean may contain custom configuration attributes and management operations.

[0160] The provider uses the lookup/validation SPI to write the custom lookup/validation implementation.

[0161] The provider uses the security provider SPI to write code that lets a server product create and use the provider. It bridges the gap between the MBean and the lookup/validation implementation.

[0162] Note that a provider may be both a builder and a validator. The administrator will configure whether the provider should be used as the realm's builder. When the builder API is called, if this provider is configured as the realm's builder, it will only be called as a builder, not as a validator. However, if it is not configured as the realm's builder, then it will be called as a validator. Regardless, when the validator API is called, the provider will be called as a validator.

MBean SPI

[0163] Two new SPI MBeans can be added: CertPathBuilderMBean and CertPathValidatorMBean. They have no methods or attributes. The provider, depending on its type, extends one or both. They both extend the CertPathProviderMBean. This allows a customer to write a provider that is both a builder and a validator.

[0164] The provider can hard-code their MBean's ProviderClassName to the name of their security provider implementation. This allows the WLS server to instantiate the provider at runtime.

Lookup/Validation SPI

[0165] The provider can write a JDK CertPathValidator and or JDK CertPathBuilder to do the actual lookup and validation.

[0166] The CertPathValidator receives an X509 certificate chain, a context handler and a list of trusted CAs. It either validates the chain or throws an exception that is propagated back to the caller.

[0167] The CertPathBuilder receives a CertPathSelector, a context handler and a list of trusted CAs. It either looks up and validates the corresponding X509 chain or throws an exception that is propagated back to the caller.

[0168] Builders and validators that require trusted CAs should use the ones passed in instead of their own list of trusted CAs. Builders and validators that do not require trusted CAs (e.g. a validator that does revocation checking) should ignore the trusted CAs.

[0169] The builder decides how much of the chain to return. If possible, it should return the entire completed chain. At a minimum, it must return the chain's end certificate.

[0170] The builder decides which types of CertPathSelectors it supports (i.e. what chain lookup criteria it supports). It throws an exception if it receives a type of selector that it does not support.

Security Provider SPI

[0171] The CertPathBuilder and CertPathValidator providers must implement the WLS CertPathProvider SPI.

[0172] The SPIs includes an initialize method. This CLV framework passes the provider's MBean to this method. The provider may use the MBean to access any custom configuration attributes.

[0173] The SPI also includes methods for returning the provider's JDK CertPathValidator/Builder implementations (providers should return null for the features they don't support). The CLV framework calls them (on each invoke) then uses the builder/validator to lookup and validate certificate chains.

Custom Console Pages

[0174] The console provides a mechanism for security providers to have custom configuration pages. CLV security providers may use this same mechanism.

Configuration API

[0175] The new attributes can be added to the RealMBean to store the CLV provider configuration.

[0176] The first, “CertPathProviders”, stores a list of the configured CertPathBuilder/Validator providers' Mbeans, in the order they should be invoked in. The list should include at least one CertPathBuilder.

[0177] The second, “CertPathBuilder”, indicates which of the realm's CertPathBuilders will be used as the builder for this realm. It must not be null—in other words, a valid realm must have a CertPathBuilder configured

[0178] Typically, providers either are pure validators, or builder/validators. For example, the out of the box (OOTB) certificate registry is both a builder and a validator, while a CRL provider which does revocation checking will just be a validator. First, the customer configures the providers, based on algorithm (i.e. I want to use XKMS and the certificate registry). Then, the customer decides which of these providers should be used for looking up certificates (i.e. which provider is the builder). That is, the customer isn't focusing on the builder/validator difference since this is a subtle distinction.

[0179] One new attribute, “DebugSecurityCertPath”, will be added to the ServerDebugMBean to turn on the CLV debugging. It is symmetrical with the other security debugging flags. The CLV framework and the out of the box CLV providers will use this attribute to turn on debugging. Third party CLV providers may use this attribute to turn on debugging.

Auditing API

[0180] The CLV framework adds two new auditing event interfaces. It uses them to post auditing events for lookup and validation failures. These auditing event classes are modeled after the other auditing event classes in the security framework.

[0181] The first, AuditCertPathBuilderEvent, which extends AuditEvent, adds attributes for the CertPathSelector that is used to lookup the certificate chain, the context handler and the list of trusted CAs.

[0182] The second, AuditCertPathValidatorEvent, which also extends AuditEvent, adds attributes for the CertPath (certificate chain) being validated, the context handler and the list of trusted CAs.

[0183] The CLV framework uses these auditing APIs to post audit events for lookup and validation failures. CLV providers may post audit events to provide more detailed information. Our OOTB providers will not.

[0184] The audit framework forwards these events to the audit providers configured in the realm. The audit providers may optionally handle or ignore these events. 7.0 and 8.1 audit providers can automatically receive these new audit events (vs. needing to implement an optional mix-in API to receive them).

Weblogic CertPath Provider

Functional Description

[0185] The WebLogic CertPath Provider is an out of the box security provider that completes and validates certificate chains by using the same trusted CA based checking that certicom uses.

[0186] WebServices must be able to validate client certificates using the same algorithms that Certicom uses. This provider satisfies this need.

[0187] An administrator can configure a set of trusted CAs for each server. This provider uses that set of trusted CAs to complete the certificate chain (if necessary). If the chain cannot be completed, then it is invalid.

[0188] The provider checks the signatures in the chain, ensures that the chain has not expired, and checks that one of the certificates in the chain is issued by one of the server's trusted CAs. If any of these checks fail, the chain is not valid.

[0189] Finally, the provider checks the chain's basic constraints (i.e. that a certificate that is not allowed to issue certificates doesn't). This can be turned off by today's existing SSL command line switch.

[0190] There are two common scenarios when this provider will be configured:

• • [0191] The administrator wants SSL and WebServices to both use the Certicom certificate validation algorithms (this is the out of the box configuration).
  • [0192] The administrator wants SSL and WebServices to both use the Certicom validation algorithm plus another CertPathValidator provider to do extra validation—e.g. certificate revocation checking.
    Functional Requirements

[0193] This provider is both a CertPathBuilder and a CertPathValidator.

[0194] Its MBean (WeblogicCertPathProviderMBean) does not add any custom configuration attributes or management operations. It uses the trusted CAs that are passed to it (by default, the trusted CAs configured for the server). It also uses the SSL command-line switch to turn off basic constraint checking.

[0195] This provider's console page should clearly indicate that the server's trusted CAs must be configured too.

[0196] It supports the EndCertificateSelector CertPathSelector. The caller passes in the chain's end certificate. The rest of the certificate chain (CAs) must be registered in the server's trust keystore.

[0197] If necessary, this provider uses the configured trusted CAs to fill in the intermediate and root CAs.

[0198] Note, if this provider is configured as a CertPathValidator, and SSL is configured to call the CertPathValidators to do extra validation, then this provider will be called. However, this provider does the same validation as the built-in SSL validation. To prevent duplicate work, this provider looks in the context for the parameters that SSL adds to indicate what level of validation SSL has already done. If these parameters are found, then this provider will not perform any validation (since SSL has already done the work).

Dependencies

[0199] The administrator can configure the WebLogicCertPathProvider via the console.

[0200] Currently, SSL only reads the trusted CAs from the trust keystore when the server is booted. This may be changed to allow dynamic trust keystore updates. If this work is done, the WebLogicCertPathProvider must refresh its trusted CAs too.

Certificate Registry

Functional Description

[0201] The Certificate Registry is an out of the box security provider that allows the administrator to explicitly register the list of end certificates that are allowed to access the server.

[0202] The certificate registry is used to store the list of valid certificates. That is, only registered certificates are valid. This provides an inexpensive mechanism for performing revocation checking. The administrator revokes a certificate by removing it from the registry. The registry must be stored in the embedded LDAP server. Because of this, customers only need to configure it once per domain vs. configuring it once per server.

[0203] The administrator can manage the certificate registry through the console—that is, register, unregister and list certificates. The administrator registers a certificate by specifying the pathname of a file containing the end certificate.

[0204] The administrator must be able to export the certificate registry from one security realm into a file then import it to another certificate registry. The file format will be proprietary and undocumented. The administrator can export a single registration to a Privacy Enhanced Mail (PEM) or Distinguished Encoding Rules (DER) file.

[0205] The certificate registry is both a builder and a validator. The administrator may configure it as the realm's builder, in which case it used as a builder and a validator, or just as a validator. When used as a builder, it locates and validates end certificates stored in the registry. When used as a validator, it ensures that the chain's end certificate is stored in the registry.

Functional Requirements

[0206] This provider is both a CertPathBuilder and a CertPathValidator.

[0207] Its MBean (CertificateRegistryMBean) does not add any custom configuration attributes. However, it adds management methods that register, unregister and list certificates. The console uses these methods to manage the registry.

[0208] Its MBean also has methods for importing and exporting certificates. The console will use these methods too.

[0209] The certificates are stored in the embedded LDAP server. Because of this, certificates are only registered once for the security realm (vs. trusted CAs which are registered in per server trust keystores). The administrator assigns each certificate a human readable alias (similar to how JDK keystores work).

[0210] There may only be one certificate registered per subject DN.

Quality of Service

[0211] The administrator registers end certificates under aliases.

[0212] This provider only validates that the certificate is registered. It does no further validation (e.g. chain validation, expiration checking).

[0213] When configured as a CertPathBuilder, the certificate registry supports the following types of CertPathSelectors:

• • [0214] IssuerDNSerialNumberSelector—the caller passes in the end certificate's serial number and issuer's DN. The registry finds the corresponding end certificate.
  • [0215] SubjectDNSelector—the caller passes in the end certificate's subject DN. The registry finds the corresponding end certificate.
  • [0216] SubjectKeyIdentifierSelector—the caller passes in the end certificate's subject key identifier. The registry finds the corresponding end certificate. Since X509 certificates are not required to have a subject key identifier, only certificates containing it may be looked up by this selector.
  • [0217] EndCertificateSelector—the caller passes in the end certificate. The registry ensures that the end certificate has been registered.

[0218] When configured as a CertPathBuilder, it must return a certificate chain (though the API/SPI does not dictate how much of the chain it must return). Since the registry only includes the end certificate, and not the CAs, it returns an incomplete chain that only includes the end certificate and none of the CAs.

[0219] The certificate registry does not use the context handler or trusted CAs that are passed in.

Management API

[0220] The CLV framework does not include a general-purpose certificate registry management MBean SPI (analogous to UserReader/UserEditor). Therefore, CertificateRegistry's MBean will include custom management methods. The console must provide custom management pages for managing the certificate registry.

Registration

[0221] The method to register a certificate/chain takes two parameters—an alias (the name the certificate chain will be registered under) and the pathname of a PEM or DER file (relative to the admin server) that contains the end certificate.

[0222] Customers may have certificates stored in keystores that they wish to add to the registry. They can achieve this by using JDK's keytool to export the certificates to PEM or DER files then using the normal registration mechanism.

DeRegistration

[0223] The method to unregister a certificate takes one parameter—the alias the certificate was registered under. The corresponding end certificate will be unregistered.

Listing

[0224] The method to list the registry takes two parameters—an alias wildcard and the maximum number of matches to return. It returns all the aliases that match the wildcard, subject to the provided limit.

[0225] It follows the MBean NameLister pattern that is used for listing users and groups. The method returns a cursor. The caller may pass the cursor into a method to retrieve the corresponding alias. The caller may also pass the cursor into methods that advance and close the list.

[0226] A console can display the contents of the corresponding certificate. The MBean will have a method that looks up the end certificate for an alias. It returns the certificate(s) as an X509Certificate.

[0227] Lastly, the MBean will contain a method that returns whether or not an alias is registered.

Copying a Certificate to a File

[0228] The MBean includes methods to copy a single certificate to a PEM or DER file. This allows the administrator to get certificates out of the registry.

[0229] One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, Rams, EPROM's, EPROM's, Drams, Rams, flash memory devices, magnetic or optical cards, Nan systems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

[0230] Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution enviromnents/containers, and user applications.

[0231] The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, steps performed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims and their equivalents.