IES20070726A2 - Automated authenticated certificate renewal system - Google Patents

Abstract

A method is provided for managing the transaction for requesting the renewal of a digital certificate between a primary server and a certificate authority, the method being carried out on a gateway server, said method comprising the steps of: (a) engaging in a first asymmetric encryption relationship between said primary server and said gateway server; (b) engaging in a second asymmetric encryption relationship between said gateway server and said certificate authority; (c) receiving a certificate signing request for a digital certificate purportedly from said primary server; (d) verifying that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship;(e) communicating said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship. <Figure 3>

Description

The present invention relates to a system that provides forth ; ai^^^ipfepewalof.> sOfJ authenticated certificates used in cryptography systems. *.jh r j «UiX CM Background to the Invention SlHo.^P The Internet has evolved as a global network, used primarily for communications (through email, file transfer, etc.) and commercial transactions (often referred to as “e-commerce”). It is common for confidential information, such as personal records or banking details, to pass between different servers on the Internet before reaching their intended destination. An environment such as this presents an enticing target for information thieves or fraudsters, looking to intercept confidential communications between parties on the Internet.

As a result, numerous cryptography schemes have been developed to provide for increased security over the Internet. Transport Layer Security (TLS), or its predecessor, Secure Sockets Layer (SSL), are examples of cryptographic protocols that provide for the secure exchange of data over the Internet. Both TLS and SSL employ what is known as Public Key Cryptography.

In Public Key Cryptography, a user has a pair of asymmetric cryptographic keys - a public key (which can be distributed to the different parties it is desired to communicate with) and a private key (which is kept secret by the user). The keys are in some way related mathematically, so that for example a message encrypted by a user’s private key can only be decrypted by that user’s public key. However, the private key cannot be easily derived from the public key.

The public key of a particular user can be distributed among their associates, which can be used to facilitate secure communication over a link that is susceptible to interception or eavesdropping. Taking as a simple example, there is a first user (Alice), and a second user (Bob), Alice and Bob each having their own respective and unique public and private key P86589IE00/, 2007 pair. A malicious third party (Mallory) is capable of intercepting communications between Alice and Bob.

If Bob wants to communicate data to Alice, Alice provides Bob with her public key prior to communication. Bob then encrypts the data using Alice’s public key, the encrypted data being communicated to Alice. At this point, while the transmission may be liable to interception by Mallory, the encrypted data can only be decrypted by someone holding Alice’s private key, which is kept secret to Alice. Alice can accordingly decrypt the data, while Mallory (being without Alice’s private key) cannot. The same set-up can apply for Alice communicating data to Bob, using Bob’s public key to encrypt the data.

A further layer of encryption can be provided by employing a public key/private key encryption process. Assuming that Alice and Bob both know each other’s public keys, Alice encrypts the data using firstly Alice’s private key and secondly Bob’s public key.

The encrypted data is then transmitted to Bob. Bob decrypts the encrypted data firstly using Bob’s private key, and then Alice’s public key, producing the unencrypted data.

This system overcomes the situation wherein Mallory may have access to some of the details of the keys used - e.g. from an attack on Bob’s system, Mallory discovers both Bob’s public and private keys. While Mallory can intercept the encrypted transmission, Mallory can only decrypt that part of the data encrypted using Bob’s public key - the portion encrypted using Alice’s private key would still be secure, as Mallory does not have Alice’s public key for the decryption.

The above examples assume that the public keys distributed by the users are authentic. One of the main problems of public-key cryptography is proving that a particular public key from a user is authentic, and has not been tampered with or replaced by a malicious third party.

Generally, a public-key infrastructure (PKI) is employed in such a situation, in which one or more trusted third party bodies, known as Certificate Authorities (CA), certify ownership of key pairs. A CA issues a digital certificate, which contains a public key for a particular user and the identity of the user. Once a user trusts a CA, the CA confirms that the public key contained in the certificate belongs to the person, organization, server or P86589IE00/, 2007 other entity identified in the certificate. A CA exists to verify the credentials of users, so that other users can trust the information in the CA's certificates. Examples of different CAs include Verisign®, Comodo, and Entrust®.

In general, the operation of a CA can be described as follows. Firstly, a CA produces a set of asymmetric key pairs, and a set of root certificates therefrom. The private keys are held by the CA and are not distributed, while the root certificates containing public keys are provided to others through controlled distribution. These root certificates can be made available to the public through a number of different methods, for example in the distribution of web browsers, operating systems or other software.

A CA receives unsigned certificates in the form of Certificate Signing Requests (CSRs), from entities that wish to apply for a digital certificate (e.g. Alice or Bob). The CSRs include information identifying the applicant entity, and the public key chosen by the entity.

For individual CSRs, the CA may attempt to validate the CSR as coming from a known party, for example through the use of a password or other confidential information from the customer. Signed certificates are produced by choosing a root or intermediate certificate, signing the certificate with the private key of the chosen root or intermediate certificate, including identification of the root or intermediate certificate with the signed certificate, and returning the signed certificate to the requesting entity.

Accordingly, a certificate typically includes the public key being signed; the name of the entity being certified; a validity period for the certificate; and the digital signature of the certificate, produced by the CA's private key.

Once a user (Alice) wishes to communicate with another user (Bob), Alice requests a certificate from Bob, which contains Bob’s public key. Alice can check the certificate received from Bob to see what digital signature was used for the signing of the certificate. Alice can then communicate with the particular CA involved to ensure that the certificate received from Bob is valid, and therefore the public key associated with the certificate is genuine.

P86589IE00/, 2007 A user may have a variety of different certificates issued by different CAs, each having different validity periods. For a large corporation, this may run into thousands if not hundreds of thousands of certificates that require management to ensure that invalid certificates are not used. Therefore, digital certificate management systems are employed in numerous organisations.

An example of a prior art digital certificate management system is illustrated in US Patent Application No. 10/918,665. With reference to Fig. 1, this system employs an abstractor server 100 that is operable to act as a proxy between the user servers 102 and the CAs 104. The abstractor 100 receives notification from a CA 104 that a particular certificate is about to expire, the abstractor 100 being operable to instruct individual user servers 102 to generate CSRs for the CAs 104, to receive the signed SSL certificate from the CAs 104, and to instruct the user servers 102 to install the signed SSL certificates. This allows for management of the various SSL certificates issued by the CAs 104.

However, such a system requires that the abstractor server 100 has root access or user servers 102 have clients installed that subsequently give root access, when instructed, to each of the user servers 102, and therefore can be vulnerable to a centralised attack on the abstractor server 100 itself. A successful attack on the abstractor server 100 would result in a malicious third party gaining root access to the individual user servers 102 in the organisation.

Therefore, it is an object of the invention to provide a system that addresses some or all of the above problems.

Summary of the Invention The invention provides a method for managing the transaction for requesting the renewal of a digital certificate between a primary server and a certificate authority, the method being carried out on a gateway server, said method comprising the steps of: (a) engaging in a first asymmetric encryption relationship between said primary server and said gateway server; (b) engaging in a second asymmetric encryption relationship between said gateway server and said certificate authority; P86589IE00/, 2007 (c) receiving a certificate signing request for a digital certificate purportedly from said primary server; (d) verifying that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; (e) communicating said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship.

This method provides for increased security when attending to the renewal of digital certificates. As there is a secure and authenticated link between the primary server and the gateway server, and also between the gateway server and the certificate authority server, it provides additional layers of protection that help to prevent malicious third parties from interfering with the communications. It does this without allowing the gateway server to have root access to the primary server.

The invention further provides a method for renewing a digital certificate on a primary server, the method comprising the aforesaid method of managing the transaction, carried out on a gateway server, in conjunction with the following steps carried out on said primary server: (a) engaging with said gateway server in said first asymmetric encryption relationship between said primary server and said gateway server; (b) generating said certificate signing request for said digital certificate; (c) communicating said certificate signing request to said gateway server in accordance with said first asymmetric encryption relationship; (d) receiving a signed digital certificate from either said gateway server or said certificate authority; (e) verifying the authenticity of said signed digital certificate; and (f) installing said signed digital certificate on said primary server.

P86589IE00/, 2007 The method involving the primary server can result in the certificate being passed through the gateway server, or in the primary server requesting and downloading the certificate from the certificate authority.

Preferably, the method further comprises the step of monitoring the expiry of the digital certificate on the primary server, said step of generating a certificate signing request based on said monitoring.

Preferably, the method further comprises the step of the primary server periodically querying the certificate authority as to the generation of the signed digital certificate.

Preferably, the method further comprises the step of, once a signed digital certificate has been generated, the primary server obtaining the signed digital certificate from the certificate authority.

Preferably, the method further comprises the step of verifying that the signed digital certificate received at said primary server has been communicated from said certificate authority.

The invention further provides a computer program product for use by a gateway server in managing a transaction for requesting the renewal of a digital certificate between a primary server and a certificate authority, said computer program product comprising instructions which when executed on a gateway server are effective to cause said gateway server to perform the following steps: (a) engaging in a first asymmetric encryption relationship between said primary server and said gateway server; (b) engaging in a second asymmetric encryption relationship between said gateway server and said certificate authority; (c) receiving a certificate signing request for a digital certificate purportedly from said primary server; (d) verifying that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; P86589IE00/, 2007 (e) communicating said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship.

The invention also provides a gateway server for use in verifying a transaction for the renewal of a digital certificate installed on a primary server, wherein: the gateway server is communicatively coupled to and associated with said primary server such that said primary server and said gateway server form an asymmetric encryption pair; the gateway server is communicatively coupled to and associated with said certificate authority such that said certificate authority and said gateway server form an asymmetric encryption pair; and said gateway server is programmed to: (a) receive a certificate signing request for a digital certificate purportedly from said primary server; (b) verify that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; (c) communicate said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship.

The invention further provides a system for the renewal of a digital certificate, the system comprising: a gateway server as aforesaid; P86589IE00/, 2007 ΙΕΟ 7 07 26 at least one primary server, said server having at least one digital certificate installed thereon; said primary server being programmed to: (a) engage with said gateway server in said first asymmetric encryption relationship between said primary server and said gateway server; (b) generate said certificate signing request for said digital certificate; (c) communicate said certificate signing request to said gateway server in accordance with said first asymmetric encryption relationship; (d) receive a signed digital certificate from either said gateway server or said certificate authority; (e) verify the authenticity of said signed digital certificate; and (f) install said signed digital certificate on said primary server.

The system may optionally include the server of the certificate authority which issues the signed digital certificate.

Detailed Description of the Invention An embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Fig. 1 shows an example operation of a prior art digital certificate management system; Fig. 2 shows an overview of the system of the invention; Fig. 3 illustrates the activation procedure of the system of Fig, 2; Fig. 4 illustrates the certificate renewal operation of the system of Fig. 2; Fig. 5 shows the system of Fig. 2 wherein the Certificate Services Gateway is part of the infrastructure of the certificate provider; Fig. 6 shows the system of Fig. 2 wherein the Certificate Services Gateway is located within the subscriber’s network and remote from the certificate provider; and Fig. 7 shows the system of Fig. 6 utilising a Hardware Security Module.

With reference to Fig. 2, an automated authenticated certificate renewal system (AACRS) is indicated generally at 10. The AACRS 10 comprises at least one user server 12 having a P86589IE00/, 2007 °726 particular software module installed on the user server 12, the software module being a Daemon or Server Service Application (DSSA). The DSSA acts to manage the digital certificates present on the user server 12. The DSSA ensures that all SSL certificates are maintained, renewed and installed transparently to the administrators. The DSSA is responsible for generating keys and CSRs, installing public key certificates, and applying security configuration on SSL/TLS configured and aware server applications (such as web servers) using its own in-built engines.

The DSSA is server software that resides on a server, or a group of servers, that typically are used to operate web servers to host web sites secured with SSL/TLS protocol or other SSL/TLS aware server applications.

The DSSA is ultimately coupled with at least one CA 14, the CA 14 being responsible for the signing of digital certificates.

In order to securely communicate with the CA 14, the DSSA software uses an intermediate network communication layer. Accordingly, the AACRS 10 further comprises a Certificate Services Gateway server (CSG) 16. The CSG 16 is responsible for securing and authenticating the network communications between the DSSA and the CA 14.

In the present embodiment, an individual CSG 16 is associated with a specific CA 14, the CSG 16 dedicated to communicating with that CA 14 only.

However, it will be understood that in another embodiment a CSG 16 may communicate with a plurality of different CAs 14, the CSG 16 having a particular association with each of the CAs 14 that it communicates with.

The CSG 16 comprises a plurality of components: • a certificate authority component for managing public key authentication certificates issued to the DSSA software, for authentication of the individual instances ofthe DSSA servers to the CSG 16; • a web server to operate the CSG 16 network gateway module, that authenticates DSSA requests and which transfers the communications to and from the CA 14; P86589IE00/, 2007 °72S • a web-based management console, to allow easy configuration and maintenance of the CSG 16 software components; and • a network time protocol client, that synchronizes the clock on the CSG 16 with a globally recognized time source for a trusted time indicator.

The DSSA software module is operable to carry out a number of instructions related to the operation of the AACRS system 10. Examples of authenticated instructions include: 1. Querying server 12 for the details of any digital certificates present. 2. CSR generation based on monitoring of digital certificate status. 3. CSR transmission to the CA 14 through the CSG 16. 4. Installing the signed digital certificate obtained from the CA 14 through the CSG 16.

. Restarting the server if required. 6. Querying CA 14 for any digital certificates that have been generated and are awaiting collection by the DSSA. 7. Generating an authentication certificate using the license key for the CA 14 so that the DSSA can authenticate its requests to the CSG 16.

The DSSA can generate a CSR, without receiving any external instruction, and sends this to the CSG 16 for authentication purposes only, before being transmitted to the CA 14 to request the SSL. The CA 14 only accepts the request if the DSSA request has been positively authenticated by the CSG 16.

When the signed digital certificate is collected by the DSSA, the DSSA authenticates the public key of the received digital certificate with the private key used to generate the CSR. If the validation is positive, the DSSA will automatically install the digital certificate.

It is envisaged that the DSSA software component may be provided to a subscriber of the AACRS system 10 as a software program to be installed on a particular server. The subscriber must then register their software to apply for a dedicated license key for their use of the DSSA software. When registering, subscribers enter their corporate and contact details to create a dedicated subscriber account for the DSSA for the particular server(s). The subscriber account is created on the CSG system 16, and is associated with a Unique P86589IE00/, 2007 Identifier (U1D) string provided by the CA 14 that is ultimately responsible for issuing the digital certificates that the DSSA will request.

It will be understood that a CSG 16 may be associated with a plurality of CAs 14, with each subscriber account created on the CSG system 16 associated with a different Unique Identifier (UID) string provided by the different CAs 14.

Upon successful registration, subscribers can obtain the unique license key that may be used with a number of DSSA software instances. It is predicted that a different license key may be required for each instance of DSSA software on a particular server, or a single license may be used for a plurality of servers on which the subscriber installs the DSSA software.

The license key contains a variety of information about the particular subscriber account, including contact details. The license key may also carry some encrypted information, known only to a particular CA system. This allows the particular CA 14 to properly verify the authenticity of the licence key and whether it is genuine.

When installing the DSSA software on a server, the subscriber can provide the correct paths for locations of the existing public key SSL certificates and associated private keys, as well as start-up and shutdown routines for the particular SSL/TLS aware server software.

The DSSA software can use a text configuration file to operate. Each software distribution of the DSSA module can be provided with a default configuration file, that contains a set of configuration keys with pre-defined values assigned. The DSSA configuration file can be easily amended, and subscribers can modify its contents to fit any particular needs, and can enable or disable various software related features. The configuration file can also store the license key generated during subscriber account registration.

To enable the DSSA software with the ability to use the CSG 14, the DSSA software must firstly register itself with the CSG, so that it can become trusted. The registration process is accomplished automatically and transparently by the DSSA software, once the DSSA software is installed by the subscriber on the server 12.

P86589IE00/, 2007 With reference to Fig. 3, the activation procedure of the AACRS system 10 can be described as follows; (A) During the installation phase, the DSSA software will obtain from its configuration file either the Fully Qualified Domain Name [FQDN] location or an IP address of the CSG 16 that is needed for the registration to occur. When registering with a specific CSG 16, the DSSA software generates a private key and uses this key to create a CSR. The DSSA software also accesses the unique subscriber license key that is stored in the configuration file.

(B) The CSR and the license key are sent to the CSG 16 for registration.

(C) Upon receipt of anew DSSA software registration request, the CSG 16 transfers the license key presented by the DSSA software to the CA 14; (D) The CA 14 verifies whether the license key is genuine (i.e. issued by the CA system during the license key generation process). Upon successful verification, the CA 14 issues a Unique Identifier (UID) string, and returns the UID string to the CSG 16 for storage. Receipt of this UID from the CA 14 is recognised by the CSG 16 as an authorisation for the CSG 16 to sign the DSSA CSR using the private key of the CSG 16. The CSG 16 creates a public key authentication certificate that is then returned to the DSSA.

(E) The DSSA then stores the returned authentication certificate, along with its associated private key, and uses these to authenticate against the CSG 16 in any future communications between the DSSA and the CSG 16.

In an alternative embodiment, the CSG 16 communicates with a plurality of CAs 14. In this case, the activation procedure described above may be altered accordingly. In step (C), the CSG 16 transfers the license key presented by the DSSA software to the DSSA software vendor for verification.

In step (D), the DSSA software vendor verifies whether the license key is genuine (i.e. issued by the vendor during the license key generation process). Upon successful verification, the DSSA software vendor issues a Unique Identifier (UID) string, and returns the UID string to the CSG 16 for storage. Receipt of this UID from the DSSA software vendor is recognised by the CSG 16 as an authorisation for the CSG 16 to sign the DSSA CSR using the private key of the CSG 16.

P86589IE00/, 2007 IE0 70726 Optionally, the activation of the DSSA component of the AACRS system 10 may be completed by the network time protocol client of the CSG 16 requesting a timestamp from a trusted time source 18. The timestamp is transmitted to the DSSA (step (F)), which is then used to configure the authorised time from which the DSSA module operates.

Once the DSSA software is installed and activated on the server 12, and is configured and registered with the specific CSG 16, the DSSA can operate without any human intervention. Digital certificate renewals on the server 12 can be completely automated by the DSSA’s time function and its ability to read the expiration time and date of the certificates it manages. When new certificates are required, the DSSA toolkit enables the manual initiation and subsequent automation of the new digital certificate instance.

With reference to Fig. 4, the certificate renewal operation of the AACRS system 10 is described as follows: (A) Once the DSSA finds an instance of a certificate that must be renewed (with reference to the authorised time), the DSSA locates its associated private key and uses it to generate a new CSR.

(B) The generated CSR is transmitted to the CSG 16. The CSG 16 authenticates the DSSA using the particular private key and public key agreed between the DSSA and the CSG 16.

(C) Upon successful authentication of the DSSA, the CSG 16 accepts the request and securely transmits it along with the UID to the CA 14.

(D) Upon successful verification of the authenticity of the UID, verification of the provided CSR and subject to subsequent validation routines, the CA 14 passes the CSR for signing. The CA 14 subsequently creates a signed certificated according to the server account details known from the UID, and stores the certificate for collection by the DSSA.

(E) The DSSA queries the CA 14 periodically until the certificate is available.

Once the certificate is available, the DSSA retrieves the certificate from the CA 14, through the CSG 16. The DSSA compares the public key in the certificate against the associated private key on the DSSA device, and stores the public key certificate in the location configured by the DSSA. The DSSA P86589IE00/, 2007 • *°70726 subsequently amends the device configuration, and restarts that certificate related application so that the renewed certificate can be used.

The use of this system allows for an automated procedure for renewal of the digital certificates of the device, which is authenticated by the presence of the CSG 16 and the unique relationship established between the DSSA server 12 and the CA 14 (based on Public Key Cryptography), and the CSG 16 and the CA 14.

The above-described sequence can also apply in the case of the installation of new digital certificates manually added to the DSSA server 12 by the subscriber.

The issuance ofthe certificate can be accomplished by the CA 14 asynchronously, as the speed of issuance can depend on the system load. Therefore, the requesting DSSA software can check the status of a particular certificate request by periodically querying the CA 14 by authenticating and communicating through the CSG 16.

As a result of this periodic querying, once the certificate is issued by the CA 14 and is available for download, the DSSA can automatically collect it, and compare the public key in the certificate against the associated private key on the DSSA server 12, and subsequently store the public key certificate in the location configured by the DSSA. The DSSA accordingly amends the device configuration, and restarts that certificate related application so that the renewed certificate can be used.

As a second factor authentication layer, the CSG 16 can authenticate each individual DSSA server 12 using another authentication technique, for example a username and password, a security token (or other two factor authentication system), to achieve a twofactor authentication architecture.

It will be understood that the security of the overall AACRS system 10 may be further increased through use of a Hardware Security Module (HSM). A HSM is often a plug-in card or external device for a general purpose computer or server, and may even be an embedded system itself. A HSM is used to securely generate and/or store long-term secrets for use in cryptography and physically protect the access to, and use of, those secrets over P86589IEOO/, 2007 ΐΕθ70?26 time. Generally, these can be private keys used in public key cryptography; some HSMs also allow for hardware protection of symmetric keys.

With reference to Fig. 7, the local CSG 16 of Fig. 6 is shown coupled with a HSM 22, the HSM 22 operable to generate and/or store keys used in the secure communications of the AACRS system 10. The private key resides inside the HSM 22, and thus the HSM 22 will participate in all cryptography related activities and operations such as establishing SSL/TLS connections, SSL/TLS Client Authentication and PKI aware messaging with CA Services.

The finer points of the AACRS system 10 configuration can be tailored to the particular requirements of the subscriber or the certificate authority in question. With reference to Fig. 5, a first system configuration is shown. Here, the DSSA server 12 is connected to the CSG 16 via the Internet 20 (or an alternative network).

The particular CSG 16 itself is located inside the network operations centre of the TLS/SSL provider, local to that CA 14 that the CSG 16 is associated with. Thus, each DSSA device must connect to the Internet 20 in order to communicate with the main CA 14 and its associated CSG 16.

In corporate networks, when large number of DSSA instances may be in use, providing access to the Internet 20 on many devices to enable communications with the CSG 16 may be seen as insecure, and may not fit the network security policy of the organisation. In this instance, the CSG 16 can be deployed locally, inside the organisation’s network infrastructure, thus reducing a security threat to the network by limiting the outgoing network traffic to this single CSG server 16.

Such a configuration is shown in Fig. 6, where the DSSA server 12 is connected to the local CSG 16, with only the CSG 16 connected to the Internet 20. The CSG 16 communicates over the Internet 20 with the associated CA 14 of the SSL/TLS provider. In complex and large network infrastructures, this solution provides network administrators a simpler method of automating the certificate life cycle, while at the same time keeping the network relatively more secure.

P86589IE00/, 2007 7θ72 As the specific CA 14 will only accept communications from a trusted and authenticated CSG 16, said communications being through relatively strong cryptography techniques (e.g. PKI), and as use of the DSSA software means that a server 12 can only communicate with a CA 14 through the specific CSG 16 associated with that CA 14, this results in additional layers of protection established for the purposes of secure certificate renewal. This ultimately leads to relatively more secure network communications.

In addition to the server querying operation that can be performed by the DSSA software, it will be understood that the CSG 16 may further comprise a scanning component. The scanning component is operable to scan the contents of the available servers for the presence of digital certificates (e.g. a number of servers within a particular IP range). Once digital certificates have been found on servers, the CSG 16 has the option of installing the individual DSSA software on that particular server in order to manage those certificates. This feature may be particularly of use when the localised CSG configuration is used, as shown in Fig. 6, where an administrator cannot keep a detailed log of when and where new certificates are installed. This scanning may be performed periodically, or may be carried out on instruction from an administrator.

The primary advantage of the AACRS system 10 is that the DSSA application on the server is an automated manager of the local digital certificates. The instructions are not transmitted to the server, rather the application carries out pre-configured instructions. The digital certificates the server receives are from an authenticated source. So all instructions are secured and occur directly on the specific server.

There exists a security association between the DSSA application and the CSG, and consequently between the CSG and the CA. A security association (SA) is the establishment of shared security information between two network entities to support secure communication. An S A may include cryptographic keys, initialisation vectors or digital certificates.

Preferably, users can subscribe to the AACRS system, and can download the DSSA software online, through a dedicated website, or they can download the DSSA software from anywhere and apply for a license key separately.

P86589IE00/, 2007 It will be understood that the system described herein may be used for the management of any digital certificates, and is not limited to SSL/TLS based systems.

The invention is not limited to the embodiments described herein but can be amended or 5 modified without departing from the scope of the present invention.

Claims (5)

Claims:

1. A method for managing the transaction for requesting the renewal of a digital certificate between a primary server and a certificate authority, the method being carried out on a gateway server, said method comprising the steps of: (a) engaging in a first asymmetric encryption relationship between said primary server and said gateway server; (b) engaging in a second asymmetric encryption relationship between said gateway server and said certificate authority; (c) receiving a certificate signing request for a digital certificate purportedly from said primary server; (d) verifying that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; (e) communicating said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship.

2. A method for renewing a digital certificate on a primary server, the method comprising the method of claim 1 carried out on a gateway server, in conjunction with the following steps carried out on said primary server: (a) engaging with said gateway server in said first asymmetric encryption relationship between said primary server and said gateway server; (b) generating said certificate signing request for said digital certificate; (c) communicating said certificate signing request to said gateway server in accordance with said first asymmetric encryption relationship; (d) receiving a signed digital certificate from either said gateway server or said certificate authority; (e) verifying the authenticity of said signed digital certificate; and (f) installing said signed digital certificate on said primary server. P86589IE00/, 2007

3. A computer program product for use by a gateway server in managing a transaction for requesting the renewal of a digital certificate between a primary server and a certificate authority, said computer program product comprising instructions which when executed on a gateway server are effective to cause said gateway server to perform the following steps: (a) engaging in a first asymmetric encryption relationship between said primary server and said gateway server; (b) engaging in a second asymmetric encryption relationship between said gateway server and said certificate authority; (c) receiving a certificate signing request for a digital certificate purportedly from said primary server; (d) verifying that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; (e) communicating said verified certificate signing request from said gateway server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in turn verified the certificate signing request as issuing from a primary server with which said gateway server has a trusted relationship.

4. A gateway server for use in verifying a transaction for the renewal of a digital certificate installed on a primary server, wherein: the gateway server is communicatively coupled to and associated with said primary server such that said primary server and said gateway server form an asymmetric encryption pair; the gateway server is communicatively coupled to and associated with said certificate authority such that said certificate authority and said gateway server form an asymmetric encryption pair; and said gateway server is programmed to: (a) receive a certificate signing request for a digital certificate purportedly from said primary server; P865891EOO/, 2007 (b) verify that said certificate signing request received at said gateway server has been communicated from said primary server in accordance with said first asymmetric encryption relationship; (c) communicate said verified certificate signing request from said gateway 5 server to a certificate authority in accordance with said second asymmetric encryption relationship; whereby said certificate authority can verify that said certificate signing request has been received from said gateway server and that said gateway server has in tum verified the certificate signing request as issuing from a primary server with which said gateway server 10 has a trusted relationship.

5. A system for the renewal of a digital certificate, the system comprising: a gateway server according to claim 4; at least one primary server, said server having at least one digital certificate installed thereon; said primary server being programmed to: (a) engage with said gateway server in said first asymmetric encryption relationship between said primary server and said gateway server; (b) generate said certificate signing request for said digital certificate; (c) communicate said certificate signing request to said gateway server in accordance with said first asymmetric encryption relationship; (d) receive a signed digital certificate from either said gateway server or said certificate authority; (e) verify the authenticity of said signed digital certificate; and (f) install said signed digital certificate on said primary server.