Systems and methods for managing digital certificates

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a continuation application of U.S. patent application Ser. No. 12/122,944, filed May 19, 2008, which in turn claims the benefit of U.S. Provisional Patent Application No. 60/938,575, filed May 17, 2007. The entire disclosures of U.S. patent application Ser. No. 12/122,944 and U.S. Provisional Patent Application No. 60/938,575 are hereby incorporated by reference herein.

FIELD OF THE INVENTION

Embodiments of the invention relate generally to digital security, and, more particularly, to systems and methods for managing digital certificates.

BACKGROUND OF THE INVENTION

In today's business environment, many systems employ communications over digital networks such as company intranets and the Internet. When these systems are used, the security of communications between parties is always a concern. To establish secure communications, a secure channel can be established, through which data can be securely passed.

A digital certificate can be used to establish a secure communication channel. A digital certificate (or identity certificate) is an electronic document which incorporates a digital signature to bind together a public key with an identity (i.e., information such as the name of a person or an organization, or an address). The certificate can be used to verify that a public key belongs to an individual or organization.

A certificate typically includes the public key being signed, a name, which can refer to a person, a computer or an organization, a validity period, the location (universal resource locator) (URL) of a revocation center and the digital signature of the certificate, produced by a certificate authority's private key.

The certificate authority or certification authority is an entity which issues digital certificates for use by other parties. It is an example of a trusted third party. A certificate authority issues digital certificates which contain public key and private key pairs. The certificate authority also attests that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A certificate authority's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the certificate authority's certificates. Examples of certificate authorities include organizations such as VeriSign, Comodo and Entrust.

Large organizations can find themselves managing tens of thousands of digital certificates every year. Each of these digital certificates has a lifecycle that includes a request for the certificate, authorization to use the certificate, management and use of the certificate, expiration of the certificate, and the request of a replacement certificate. Management of the lifecycles is further complicated by the fact that certificates typically expire a year after they are issued, with the issuance of certificates occurring on a continuous rolling basis. Managing tens of thousands of certificates that are expiring on a rolling basis is an arduous and complex task.

A typical problem that occurs with such certificate management includes the difficulty of manually managing the certificates. This is because requests for certificates, related authorizations and distribution of the certificates are typically accomplished via a series of e-mail exchanges that are performed in an ad hoc manner. Such management of certificates can lead to a lack of accountability and a lack of appropriate escalation when the intended recipient of a certificate does not respond to an e-mail communication.

Thus, there is a need for an improved system and method for managing digital certificates within an organization.

SUMMARY OF THE INVENTION

Embodiments of the invention satisfy this and other needs by providing improved systems and methods for managing digital certificates.

Embodiments of the invention provide for methods and systems that manage the lifecycle of certificates. The methods and systems can provide one or more functionalities such as automating the certificate lifecycle management system, avoiding negative impact on clients due to expiring certificates, improving accountability and escalation, aligning with line of business (LOB) operational models, providing greater transparency to LOBs via self-administration and accommodating un-managed certificates (i.e., self-signed) in the firm.

A method of managing a digital certificate by a computer system can include the steps of receiving, the at the computer system, a business request for a digital certificate from a requester and transmitting, by the computer system, the request to a first approver. The method can further include, upon approval by the first approver, transmitting, by the computer system, the request to a second approver, upon approval by the second approver, transmitting, by the computer system, the request to a certificate manager, transmitting, by the computer system, the request to an implementer and receiving, by the computer system, from the implementer, technical information related to the request and transmitting, by the computer system, a certificate to a certificate supplier.

Thus, by way of embodiments of the invention, a large organization can efficiently manage the life cycle of digital certificates.

BRIEF DESCRIPTION OF THE DRAWINGS

Objects and advantages of the invention will become apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 is a high level block diagram of a certificate management system, in accordance with certain embodiments of the invention;

FIG. 2 is a high level block diagram showing the flow of information through a certificate management system, in accordance with certain embodiments of the invention;

FIG. 3 is a flow diagram illustrating a process of certificate creation, in accordance with certain embodiments of the invention;

FIG. 4 is a system diagram showing an information flow between entities, in accordance with certain embodiments of the invention;

FIG. 5 is an exemplary screenshot of a home page of a certificate management system, in accordance with certain embodiments of the invention;

FIG. 6 is an exemplary screenshot of a certificate request page of a certificate management system, in accordance with certain embodiments of the invention;

FIG. 7 is an exemplary screenshot of a requestor information page of a certificate management system, in accordance with certain embodiments of the invention;

FIG. 8 is an exemplary screenshot of a deployment information page of a certificate management system, in accordance with certain embodiments of the invention;

FIG. 9 is an exemplary screenshot of a create new request page of a certificate management system, in accordance with certain embodiments of the invention; and

FIG. 10 is a schematic diagram of an exemplary hardware implementation of a certificate management system, in accordance with certain embodiments of the invention.

It is to be understood that the above-mentioned drawing figures are provided solely to assist in describing the concepts of embodiments of the present invention.

DETAILED DESCRIPTION

With reference to FIG. 1, there is shown a high level logical block diagram of a certificate management system 100 in accordance with certain embodiments.

A user of the system 100 can access the system via a user workstation 110. Workstation 110 can be a personal or other computer, communicatively coupled to a network such as an intranet or the Internet. The user accesses the system via a Web browser at workstation 110. In one embodiment, the application is intranet-based with access by a user through a Web browser, with no other special tools or software required.

Workstation 110 allows a user to access, and communicate with, certificate lifecycle management module 120. The lifestyle management module 120 comprises two sub-modules or tiers, a client tier 122, and a business/middle tier 124. Client tier 122 presents information (e.g., user entry forms, data) to the users providing a common look and feel across the system 100. In one embodiment, the technology at this tier includes standard technologies (e.g., the HTML JavaScript programming languages). The client tier 124 is responsible for rendering user display and input pages and performing client side validations while offloading the complex business rules and database queries to the business/middle tier 124. In this embodiment, the client tier 122 interacts with the business/middle tier 124 using the industry standard Struts framework.

The business/middle tier 124 enforces all of the business logic employed by system 100, including, for example, workflow, form/data validations and processing. In one embodiment, business/middle tier 124 utilizes industry standard technologies for applications (e.g., Java and the Spring Framework programming systems). The business/middle tier 124 acts as the bond between the data tier 130 and the client tier 122. The business/middle tier 124 performs functions such as pooling, transaction support, as well as other functions. The business/middle tier 124 receives data requests from the client tier 122, processes the data, and responds back to the client tier 122. To satisfy a request from the client tier 122, the business/middle tier 124 communicates with the data tier 130.

In one embodiment, client tier 122 and business/middle tier 124 can reside on the same server. In other embodiments, each tier can reside on a different server.

Business/middle tier 124 can be communicatively coupled to data tier 130. Data tier 130 provides the storage medium for any data that is retained by system 100. In some embodiments, data tier 130 can include one or more databases stored at one or more servers. The database can use database technology, such as systems provided by Oracle. An industry standard communication framework, such as that provided by iBatis, can provide communication between the business/middle tier 124 and data tier 130. Data stored at data tier 130 can include user information, business organizational hierarchy information, certificate information, certificate status, creation and termination dates, as well as other system information.

The business/middle tier 124 interfaces and integrates with external systems 140. External systems 140 can include certificate services providers (e.g., VeriSign VICE). Services and/or data (e.g., internal reference data, authentication/authorization rights, and mail services) can be shared with external systems 140. Examples of data that is shared with external systems 140 can include User standard identification (SID), e-mail messages, line of business information, job title information, as well as other relevant data. The sharing of data with external systems can require authorization information, such as a VeriSign authorization and related password information.

With reference to FIG. 2, there is shown a certificate management system application work flow 200.

A user 220, using a Web browser, can access certificate lifecycle management system 210. When accessing system 210, a user can access any one of three main modules: certificate lifecycle management module 214; reporting module 216; and administration module 212.

Certificate lifecycle management module 214 provides a facility for businesses or business units to request, renew, replace and revoke certificates. Reporting module 216 provides aggregated and detailed information about a certificate lifecycle to users. In one embodiment, reporting is accomplished via Java reports built within system 200. Data is stored at an Oracle database. Administration module 212 provides configuration management for components of the application (e.g., general user and certificate information, line of business specific information, user entitlements, notifications, workflow, as well as other components). In some embodiments, notifications (e.g., via email or other communication channels) can be sent to appropriate parties to alert the parties of impending deadlines, such as the expiration of a certificate, or a delay in the certificate requesting process. The alerts can be issued at predetermined times, such as, for example, at 90 days before the expiration of a certificate. As discussed in further detail below, if appropriate action is not taken, an escalation process can cause alerts to be sent to additional parties at predetermined times, such as, for example, five day prior to expiration of a certificate, to facilitate resolution of the process.

With reference to FIGS. 3 and 4, an exemplary certificate creation flow 300, by way of entities 400, in accordance with some embodiments, is illustrated. First, a requestor (410) creates a business request (430). Step S302. As used herein, a requestor is any authenticated user who requests and/or owns a certificate at a given instance. The business request (430) is then saved as a draft. Step S304. As used herein, a draft is a business request that is saved but not submitted. This business request may have fields that are not yet filled. The user can enter the available information and then save the business request as a draft to fill it at a later time. A business request can be saved as a draft for a maximum of some predetermined number of days (e.g., 30 days) after which it is removed from the certificate management system. If the draft remains on the system for more than a predetermined amount of time (e.g., more than thirty days), the draft request is deleted from the system. Step S306.

If the requestor (410) submits the request (430) to an approver (450), and the approver (450) does not approve the request (430) (step S308), then, the request (430) is returned to the requestor (410), returning to step S302. As used herein, an approver is an information owner or an alternate authority who is accountable for the verification, validation, and authorization of the requestor's business request, based on the business need.

If, however, the approver (450) approves the request (430) (step S308), the request (430) is passed on along the process, to step S310.

At step S310, if the related business purpose has an information risk manager (IRM) approver (440), then the request (430) is passed to the IRM approver (440) at step S312. As used herein, an Information Risk Manager (IRM) is a person assigned to review the potential risk impact of a particular certificate request prior to the fulfillment of the request. The information risk manager is responsible for coordinating all business compliance requirements in accordance with the company's information technology (IT) risk management policies and standards to ensure compliance. In some embodiments, the use of an IRM approver is optional. If the IRM approver (440) does not approve the request (430) at step S312, then the request (430) is returned to the requestor (410) at step S302. If the IRM approver (440) approves the request (430) at step S312, the request (430) is passed along to a certificate manager (420) at step S314. As used herein, a certificate manager is a person who can assign implementers and monitor certificate lifecycle events for his specific line of business (LOB), or certificate type.

Also, if there was no IRM approver (440) for the related business purpose (at step S310), then the request (430) is passed directly to the certificate manager (420) (at step S314), without passing through an IRM approver (440).

Then, at step S314, the certificate manager (420) selects an implementer and the request is passed to the implementer at step S316. As used herein, an implementer is a person responsible for generating the key, CSR (i.e., a file that contains the certificate details such as the distinguished name), and updating the certificate request details with technical metadata.

If the implementer has entered technical information (step S316), then a certificate (460) is sent to a certificate supplier. Step S322. As used herein, technical information (or deployment information) includes information such as CSR, server name and IP address, deployment configuration, and environment that is entered by the implementer for each certificate. As used herein, a certificate supplier is a certificate vendor, as described above.

If the implementer has not entered technical information (step S316), then the request remains in a queue for a predetermined period of time (e.g., 90 days). Step S318. If the technical information is entered during the predetermined period (step S318), then a certificate (460) is sent to the certificate supplier. Step S322. If, on the other hand, technical information is not entered during the predetermined period (step S318), the request (430) becomes a void request. Step S320.

The security administrator 470 is the administrator of the system facilitating the certificate lifecycle management functions.

In some embodiments, the system can include an escalation coordinator, a person responsible for maintaining the escalation profile/attributes of various certificates. Contact information, such as e-mail addresses, for requestors 410, approvers, 450, implementers 418, as well as an escalation coordinator can be stored by the system. If the system determines that action by a party is needed, such as, for example, renewal of a certificate, or response to a certificate request, the system can alert, for example, via e-mail or other communications, the responsible party. If the responsible party does not respond within a predetermined amount of time, another party, such as the escalation coordinator, can be alerted, to facilitate smooth operation of the certificate management process.

When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period, thus causing the certificate to be revoked. Certificates can be revoked for several reasons, as are known to those of skill in the art. An example of a reason for certificate revocation is that a certificate is no longer being used by a business unit, because a corresponding Web site has been decommissioned. In addition, a certificate can be revoked because the certificate has become corrupted, or requested incorrectly with incomplete or incorrect request information.

In some embodiments, a security administrator 470 can be alerted by the system about circumstances warranting revocation of a certificate. The security administrator can then take certain steps to revoke the certificate.

When a request for a certificate has been approved, a certificate can be issued from a certificate authority 414.

In some embodiments, actions taken during the certificate management process can be time stamped with the date and time the actions are performed.

With reference again to FIGS. 1 and 2, in some embodiments, external systems 140 of system 100 can include an automated provisioning module. Upon approval of a certificate, the provisioning module can facilitate the automatic insertion of a certificate on the appropriate computer system, without the need for human interaction. The provisioning module can include one or more software modules located at servers of the certificate management system 100. In some embodiments, the provisioning module obtains certificate information stored at data tier 130 about a requested certificate, and correlates the certificate information with an appropriate receiving server or other computer, to insure that the correct certificate is being installed on the appropriate system. In some embodiments, the provisioning module can be used to automatically de-provision or remove a certificate from a server or computer, if the certificate is revoked or it is otherwise determined that the certificate is to be removed. In some embodiments, the provisioning module can deliver a certificate to an agent module, which then performs the local installation of a certificate.

In some embodiments, external systems 140 of system 100 can include a discovery module. The discovery module can include one or more software modules configured to probe servers and other computers used within the business environment of a company, business unit, institutional clients and/or internal clients. The discovery module can probe servers and/or computers of the client and detect certificates on the computers. The discovery module can then compare information about detected certificates with information about the status of known certificates stored at the data tier 130. By way of such detection and comparison, the discovery module can automatically determine, for example, if certificates exist that are not in the inventory stored at data tier 130, or if one or more certificates have a different status (e.g., revoked) than is indicated in the inventory information at data tier 130.

In some embodiments, system 100 can keep track of the relative priority of different certificates, and include the certificate priority information in communications and alerts described above. In addition, certain operational parameters, such as predetermined times for transmitting communications and alerts, as well as predetermined times and circumstances to trigger escalation of communications can be based, at least in part, on the relative priority of a certificate, with the processing of higher priority certificates generally involving more frequent communications, and more aggressive escalation and alerting communications.

As described above, users employ the certificate management system by accessing and interfacing with various user interface screens via a Web browser. Certain exemplary user interface screens are discussed below.

With reference to FIG. 5, in certain embodiments, the home page 500 is the first page that appears after a user is authenticated by the system. Options that appear on this page are based on the role and permissions of the user. One or more of the following information fields can appear on the home page: user name; broadcast message; current date and time. From this screen, a user can to search for specific certificates and view their details. A user can search for certificates based on criteria such as business requestor standard identification (SID), and application name.

The left navigation pane can contain links that allow a user to navigate to various pages within a module. The links that appear on this pane depend on the role and permissions of the user. The summary section contains links and the number of certificates or business requests in different category sections, including the following: Certificates I Request, Certificates I am Approver for, Certificates I am Implementer for, Certificates I am Certificate Manager for, and Certificates I have de-provisioned. These sections contain details on business requests or certificates. Selecting the appropriate section bar allows a user to view more details, as follows.

Certificates I Request: selecting this link opens the Certificates I Request section. The Certificates I Request section contains the Submitted, Draft, and Need to Assign Implementer sub-sections.

Certificates I am Approver for: selecting this link opens the Certificates I am Approver for section. The Certificates I am Approver for section contains the Waiting for My Approval, On Hold, Approved, and Rejected sub-sections.

Certificates I am Implementer for: selecting this link opens the Certificates I am Implementer for section. The Certificates I am Implementer for section contains the Implemented and Waiting for MY Implementation sub-sections.

Certificates I am Certificate Manager for: selecting this link opens the Certificates I am Certificate Manager for section. The Certificates I am Certificate Manager for section contains the Submitted and Need to Assign Implementer sub-sections. This section appears only for a Certificate Manager and a Security Administrator.

Certificates I have de-provisioned: selecting this link opens the Certificates I have de-provisioned section.

With reference to FIG. 6, a Certificates Request screen 600 is shown. The Certificates I Request section contains the certificates that a user has requested. This section contains three sub-sections: Submitted, Draft, and Need to Assign Implementer.

FIG. 7 shows a requestor information screen 700. The requestor information screen can include one or more of the following sections: Requestor's Information; Application Information; LOB Information; Certificate Request Information; Approver Information; IRM Approver Information; Authorized Contact Information; Deployment Information; and Requestor's Information

The Requestor's Information section contains details of the requestor.

The Application Information section contains details of the application. The Application Information section contains two options: App Quest Application and Non App Quest Application. To select the application name, a user selects the Click here to Select Application link.

With reference to FIG. 8, there is shown a Deployment Information screen 800. The Security Administrator or LOB Administrator specifies whether it is mandatory, optional, or not required for a user to enter deployment information when creating the request. If it is mandatory to enter the deployment information, then a business request cannot be submitted unless the deployment information for all certificates is completed.

In some embodiments, a user can fill deployment information for certificates only after a user selects the business purpose in the Business Purpose list box. To fill the deployment information for each certificate, select the Add Technical Info check box and then click Add. If a user click Add without selecting the business purpose in the Business Purpose list box, an error message appears.

A Create a Business Request for Certificates screen 900 is shown in FIG. 9. Any authenticated user can submit a request for certificates. To create a business request for one or more certificates, on the Certificate Management tab, a user selects the Initiate Certificate Request link on the left navigation pane. The Create New Request page can include one or more of the following sections: Requestor's Information; Application Information; LOB Information; Certificate Request Information; Approver Information; IRM Approver Information; Authorized Contact Information; Deployment Information; and Requestor's Information.

The Requestor's Information section contains details of the Requestor. Some of the mandatory fields are system-populated and read-only.

The Application Information section contains details of the application. The Application Information section contains two options: App Quest Application and Non App Quest Application. The App Quest Application option is selected by default. To select the application name: Click the Click here to Select Application link.

The Total Cost box shows the total cost for the requested licenses. The Certificate Request Information section contains details of the certificate request. The Approver Information section contains details of the Approver.

The IRM Approver Information section contains details of the IRM Approver. If the selected business purpose does not require an IRM Approver's approval, then the IRM Approver Information section bar is disabled. The name of section changes to IRM Approver Information is not required and the section is hidden.

The Security Administrator or LOB Administrator specifies whether it is mandatory, optional, or not required for a user to enter deployment information when creating the request. To save the business request as a draft before adding technical information, click OK.

With reference to FIG. 10, there is shown an exemplary hardware implementation 1000 of certain embodiments, as described above. A user accesses the certificate management system from a user computer 1040 such as a desktop computer, laptop computer, notebook computer, or handheld device. The user computer 1040 is communicatively coupled to an application server 1020 running software to execute the certificate management system 1000. The communicative coupling can be via a network connection such as the Internet, an intranet, and/or a wireless communication channel. The application server 1020 is likewise communicatively coupled to database server 1030, which runs database management software and facilitates the transfer of data from and to one or more databases. Embodiments of the certificate management system 1000 can be implemented with more or less servers and/or user computers, in similar or different configurations, as would be known to one or skill in the art, as informed by the present disclosure.

In certain embodiments of the invention, all of the steps of the method can be performed by a computer, or computerized system, as described above. In alternative embodiments, one or more of the steps can be performed manually, by a person.

In alternate embodiments of the methods described herein, additional steps may be added, certain steps may be excluded, certain steps may be performed multiple times, and/or the steps may be performed in a different order and/or simultaneously.

While certain systems and methods have been described herein relative to the tracking and management of digital certificates, the systems and methods can also be used to manage, track, install and/or un-install other types of electronic documents or information, such as, for example, digital keys, password management information, secure shell (SSH) protocol communication information, as well as others, as would be known to one of skill in the art, as informed by the present disclosure.

It is to be understood that the exemplary embodiments are merely illustrative of the invention and that many variations of the above-described embodiments can be devised by one skilled in the art without departing from the scope of the invention. It is therefore intended that all such variations be included within the scope of the following claims and their equivalents.