text:
Disclosed herein are several digital certificate discovery and management systems. Detailed information on various example embodiments of the inventions are provided in the Detailed Description below, and the inventions are defined by the appended claims.
1. A method for automatically managing placement of digital certificates to client devices from a certificate management system, the certificate management system including network facilities for communication over an electronic communication network, the method comprising the steps of:
receiving requests for connections from clients,
attempting to retrieve a digital certificate from the client device by way of the network facilities and a client executable component,
if in said attempting a digital certificate is retrieved, checking for expiration of the retrieved digital certificate,
if in said attempting a digital certificate is retrieved, querying a revocation server by way of said network facilities for revocation of the retrieved digital certificate,
if the retrieved digital certificate is expired or revoked, retrieving a newly issued certificate from a network certificate server,
if in said attempting a digital certificate is not retrieved, accessing a certificate store to retrieve an authentication certificate,
following said accessing a network certificate server to retrieve an authentication certificate, placing the retrieved authentication certificate in the certificate store of said client device, and
authenticating the client device for data transfer.
2. A method according to
3. A method according to
4. A method according to
5. A method according to
6. A method according to
7. A method according to
8. A method for automatically managing placement of digital certificates to client devices from a certificate management system, the certificate management system including network facilities for communication over an electronic communication network, the method comprising the steps of:
receiving requests for connections from clients,
attempting to retrieve a digital certificate from the client device by way of the network facilities and said client executable component,
if in said attempting a digital certificate is retrieved, checking for expiration of the retrieved digital certificate,
if in said attempting a digital certificate is retrieved, querying a revocation server by way of said network facilities for revocation of the retrieved digital certificate,
if the retrieved digital certificate is expired or revoked, retrieving a newly issued certificate from a network certificate server,
if in said attempting a digital certificate is not retrieved, accessing a certificate store to retrieve an authentication certificate,
following said accessing a network certificate server to retrieve an authentication certificate, placing the retrieved authentication certificate in the certificate store of said client device, and
authenticating the client device for data transfer.
9. A method according to
10. A method according to
11. A method according to
12. A method according to
13. A method according to
14. A method according to
15. A method according to
16. A method for automatically managing placement of digital certificates to client devices from a certificate management system, the certificate management system including network facilities for communication over an electronic communication network, the method comprising the steps of:
receiving requests for connections from clients,
attempting to retrieve a digital certificate from the client device by way of the network facilities and said client executable component,
if in said attempting a digital certificate is retrieved, checking for expiration of the retrieved digital certificate,
if in said attempting a digital certificate is retrieved, querying a revocation server by way of said network facilities for revocation of the retrieved digital certificate,
if the retrieved digital certificate is expired or revoked, retrieving a newly issued certificate from a network certificate server,
if in said attempting a digital certificate is not retrieved, accessing a certificate store to retrieve an authentication certificate,
following said accessing a network certificate server to retrieve an authentication certificate, placing the retrieved authentication certificate in the certificate store of said client device,
authenticating the client device for data transfer, said authenticating identifying the client device to the certificate management system, said authenticating further identifying a user to the certificate management system;
providing access to services conditioned on the enablement of the services for the identified client device and user.
17. A method according to
18. A method according to
19. A method according to
20. A method according to
21. A method according to
22. A method according to
23. A method according to
This application claims the benefit of U.S. Provisional Application No. 60/495,864 filed Aug. 15, 2003 and U.S. Provisional Application No. 60/586,429 filed Jul. 8, 2004, both of which are hereby incorporated by reference in their entirety.
The claimed inventions relate generally to management of public key infrastructure server networks, and more particularly to systems that can automate the installation, renewal, detection or management of public key infrastructure digital certificates in a secure network system.
Disclosed herein are several digital certificate discovery and management systems. Detailed information on various example embodiments of the inventions are provided in the Detailed Description below, and the inventions are defined by the appended claims.
Reference will now be made in detail to systems and methods for discovering and managing digital certificates which may include some more specific embodiments of the claimed inventions, examples of which are illustrated in the accompanying drawings.
Public key infrastructure (PKI) has recently become widespread in use, particularly with the availability of public networks that provide access to confidential sources or sinks of information, for example e-commerce over the Internet. PKI is utilized in many network systems to encrypt data transacted between a user on a client device and a server, and also to verify that the client is linked to an authentic server device, particularly when the data transactions pass through an uncontrolled or insecure network portion.
Data encryption generally is of one of two types, which are symmetric and asymmetric cryptography. Speaking at a basic level, in symmetric cryptography a single key is shared by the encryptor and the decryptor, i.e. the encryption key can be used to decrypt data encrypted with that key. In
In public key cryptography one of the keys may be made public, which may serve to either to secure data from unauthorized access or digitally sign transmitted data. By digitally signing data, the receiver may verify that the received data comes from a particular sender and that the data has arrived unmodified. Referring now to
Referring now to
In a variation of the procedure of
Public key infrastructure (PKI) is the equipment and software required to practice public key cryptography for real-world applications, and may take any number of forms. In one form, PKI may include a sender computer and a receiver computer, with software for encrypting and decrypting messages, such as email messages. Often, PKI provides a facility for the retrieval of a public key from the data sender or the intended recipient, permitting encrypted communication without the need of physical public key transfers. In another PKI form, public keys are provided by way of certificates. A PKI certificate is a data structure that provides a public key to others. PKI certificates may be made available by way of network servers to others with access to that network, thus providing an efficient way of distributing public keys.
In a commonly used PKI, certificates also include a signature to verify the source of the certificate. Again, PKI keys are provided in pairs, one being held private and the other distributed publicly. The recipient of a public key may communicate with the holder of the corresponding public key in a secure fashion, but if the recipient obtained the public key over a network he may not know what the source of that public key is. It is therefore possible, in that circumstance, for a third party to trick or "spoof" the recipient party into holding communications with him, if he can provide a substitute certificate to the recipient party and if the third party's communications are sufficiently authentic to complete the deception. In a related technique of interception, a third party may form an encrypted communications link with a destination server, provide a substitute certificate to a recipient, and masquerade as the destination server by passing data between the recipient party and the destination server. The third party may then view all traffic between the recipient and the destination server unencrypted. This technique is often referred to as a "man in the middle attack", and can be a serious problem for many entities, such as banks or on-line stores, wishing to correspond with customers, employees and others over public and/or uncontrolled networks.
To solve this problem a number of Certificate Authorities (CAs), for example Verisign and Entrust, have created services for authenticating certificates. These entities hold themselves out as entities of trust, providing certificate signing services for certificate verification. The operation of a CA is generally as follows. First, a CA produces a set of asymmetric key pairs, and therefrom a set of root certificates. The private keys are secretly held by the CA, while the root certificates containing public keys are provided to others through controlled distribution. These root certificates are made widely available to the public, for example in the distribution of web browsers, operating systems or other software. Next, a CA receives unsigned certificates in Certificate Signing Requests (CSRs), which contain sufficient information to produce a signed certificate and optionally to verify the source of the individual CSRs. 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 certificate, signing the certificate with the private key of the chosen root certificate, including identification of the root certificate with the signed certificate and returning the signed certificate to the requesting party.
A standard certificate specification, referred to as X509 has been established to provide a common readable certificate format for publicly accessible utilities. This format will be recognized by those of ordinary skill in the art, and will be only briefly commented herein. The X509 format provides an example of a usable certificate format, noteworthy format items being a version number (the version of the X509 standard being used), a public key, a signature value, a denotation of the signature algorithm used, a period of validity, and an issuer identification among other format items. Although this format has seen recent widespread use, especially in https and secure shell technologies, other formats may be used with equally good results.
A client receiving a certificate from a server may verify a signed certificate by doing the following. First the client may review the certificate to see what certificate was used for signing (i.e. a parent certificate). If the parent certificate is recorded at the client's location, it may locate it and extract the public key. If the parent certificate is not known to the client, the client may request the parent certificate from an accessible server. Upon receipt of the parent certificate, the client may extract the public key. Having the public key, the client may then verify the signing of the child certificate. If the parent certificate was obtained remotely, the client may continue by verifying the signing of the parent certificate. That procedure may continue through a chain of certificates until reaching a known certificate, or reaching an unsigned or unavailable certificate. Should the process end without reaching a known certificate, the client may consider the child certificate (and other certificates in the chain) to be untrustworthy, and may provide a warning to a user.
Referring now to
Certificate Life Cycle
A certificate is normally used for a limited amount of time for a number of reasons. Certificates are priced according to the length of the validity period. This pricing is not merely for profit making, as there is an expense associated with maintaining the certificate authority infrastructure, i.e. maintaining servers that can validate issued certificates. A service provider may therefore not wish to purchase a certificate lasting a lengthy period of time, particularly if the certificate is to be used in a test or uncertain venture. Additionally, the longer a certificate is in existence and/or service, the more likely the private key will be discovered. An attack on a PKI key pair is thought to best be performed by an exhaustive search for a private key that decrypts intercepted encrypted data. Test searches are known to have been successfully conducted using supercomputer clusters in a period of months against keys of typical size. A longer period of use means that, first, an attacker will have more time to perform the search and, second, an attacker may have more intercepted data to validate the resulting possible private keys that are found. Additionally, certificate validity periods may be especially important when considering insiders, administrators and other internal employees having access to SSL servers may have additional opportunity to compromise private keys through their administrative access.
Having a limited service life of certificates requires intervention and/or certificate renewal upon the expiration of the validity of those certificates. Recent experience with PKI enterprises has shown that certificates are too often not properly renewed before expiring. Should a certificate expire unnoticed, the associated service may become unavailable. Should the PKI continue to operate, users are likely to experience warning messages, which may cause those users to avoid using the service. The service may further be subjected to an increased probability of a compromise, with devastating consequences. Should a certificate renewal failure occur for a large enterprise, for example a large Internet seller or lender, significant revenues may be lost.
The causes of certificate renewal are many in number, a few of which are noted here. An entity may fail to note the expiration of a certificate. The certificate authority may send a reminder by postal or e-mail, with some chance of mis-delivery. For example, the certificate authority may have a postal or e-mail address that has changed due to the entity moving or changing its domain name. If the entity is located overseas, there is also an increased opportunity for the notification to suffer delay. If the entity maintains a manual certificate database, there is a chance for an erroneous or missing entry. Furthermore, a notification may be missed by an administrator, which individual may be busy, on vacation, incompetent or terminated. For larger organizations, there may be several administrators multiplying that problem. Additionally, the process of renewing certificates has been a manual process, and subject to typos and other technical errors.
Service entities have operated for months and years ignorant of the dangers of expiring certificates. When the problem is discovered, it may be too late to recover without downtime of the enterprise. Should an entity face such a crisis, there are presently no tools for surveying the certificates in service. The administrators may then find themselves visiting every server of the enterprise, creating a compilation of the certificates installed and the relevant expiration dates. As certificates are renewed, the administrators may update the compilation to get a handle on the schedule of certificate renewals. Again, this is a manual process and subject to human errors, which process puts an entity at risk of downtime and loss of income or services to clients or customers. For very large enterprises having thousands of certificates, the certificate renewal workload may require the attention of several administrators, which increases the expense of the operation.
Disclosed below are a number of systems and methods useful in environments of certificate management. Some of the disclosed systems serve a single function related to certificates. Others combine several of those functions into more comprehensive systems. Of the many potential combinations most, if not all, are useful, and therefore combinations may be chosen for particular circumstances of certificate management.
Individual disclosures herein may take the form of computer systems performing functions by software, software executable by a computing system, or a group of functions performable by a computing or software system to achieve various functions, or other forms. The reader should recognize that wherever disclosure is made of one of these types below, the others will also be made apparent.
Certificate Inventorying Systems
Certain of the systems disclosed herein relate to discovering and inventorying certificates installed to a set of network servers. In a first exemplary system, a database is maintained containing records relating to inventoried certificates. Each record identifies a certificate and a server to which the certificate resides or is installed. For each certificate, an expiration date or time may also be noted, by which the expiring of certificates may be noticed. Likewise, an expiration period may also be noted. Notation may also be made in certificate records for an issuing certificate authority. Other items of data relating to certificates may also be tracked, for example the common name, organization, an identification of a responsible individual, the strength of the encryption keys, etc. Expired certificates may also be tracked in a database, if desired.
Such a certificate database may be maintained using common file formats, for example CSV or dBase formats without becoming unwieldy, as the number of certificates tracked in a typical organization will be relatively small. A certificate database might also be maintained in a relational database server, which may provide additional search, remote access, encryption and other helpful database functions. Access to a certificate database may be controlled. In the exemplary system access to the database is provided only to authenticated persons and/or applications. A certificate database may take many other forms as desired, the details of which are not particularly important.
Entries and modifications to the certificate database may be performed manually, or applications may be provided for managing certificate entries in the database through the use of graphical user interfaces, web interfaces, or many other techniques. Entries may also be made by a certificate scanner, which will be described shortly. A database of related servers, i.e. servers on which certificates reside or servers within a defined network, may also be kept. Such a server database may be kept separately from a certificate database, or may be integrated in the same database, file or data structures.
A certificate database may be maintained to provide information regarding the state of certificates in a network at given times. This may be used, in one example, by an administrator to identify certificates due to expire, or certificates that have expired. In another use, certificates may be related to servers to identify unused or duplicate certificates. In yet another use, a survey may be conducted using the database to identify certificate authorities being used, a schedule of certificate renewals, encryption strengths, certificates on a particular domain, or other reviews useful to manage a secure network system.
A certificate inventorying system may additionally include a certificate discovery tool for locating certificates in a chosen network. The discovery tool may receive as input a network address range, which in one example includes an IP address and subnet mask for an IP protocol network. In another example, a list of IP address ranges are given. For other network types, a network name, SSID name or other identifier may be used in accordance with the network's addressing standards.
Referring now to
At each address iterated through, steps 1212 through 1222 are executed in a subroutine. First, an attempt to connect with the device at the currently iterated device is made over the network, as in step 1212. If the attempt is unsuccessful, the subroutine may exit, as in step 1214. Should a successful connection be made, an attempt to retrieve a certificate will be made, as in step 1216. If a certificate is not available, decision 1218 causes an exit of the subroutine, as there is no certificate information to record. Otherwise, the subroutine parses a received certificate for items of interest, as in step 1220. The items of interest may be any information related to the received certificate, but might be a certificate identifier, an expiration date, in one example. The parsed information may then be recorded to an entry in the scan database, as in step 1222, optionally with other related information such as the current network address, server type, or other information.
The procedure shown in
A discovery system may provide for log production of the discovery process. The log might show any of items such as: addresses scanned, ports scanned, failed and/or successful connection attempts, addresses with no response, certificate identifiers and other certificate information, server software types and version numbers, modifications to an existing certificate database, and many other items as desired. A discovery system may additionally combine the results of scans conducted at different times, which may be useful to catch servers which may have been inoperative at a particular time. Although the procedure of
A certificate discovery system may detect certificates that are not used, and may report those unused certificates to an administrator. Discovered certificates may also be archived, avoiding the need to provisioning of new certificates should a server crash or otherwise become inoperable. If private keys are also discovered, those can also be archived if desired. Other systems as disclosed below may also report unused certificates or archive certificates as desired, managed or otherwise.
Certificate Installation/Renewal Systems
Other systems may be fashioned to assist with the installation and renewal of PKI certificates. Those systems may assist with the issuance of a certificate and may perform steps to install certificates to appropriate server destinations and other PKI devices.
Referring now to
The installation of newly issued certificates may proceed as follows. First, it may be necessary to request and receive a certificate from a certificate authority, if it is not desired to use an internally-generated certificate. A common method of certificate receipt is by e-mail received at the same computer from which a certificate signing request was submitted. For a signed certificate received from a certificate authority, it may be necessary to determine a destination server for the certificate upon receipt. For example, if the certificate is a renewed certificate for a certificate about to expire, it may be desirable to install the certificate to the server storing the expiring certificate. Alternatively, a certificate may under some circumstances be held prior to installation. In one situation, it may be desirable to request renewed certificates well in advance of the expiration of old certificates. The old certificate is, in that situation, allowed to age before installing the renewal certificate. In another situation, a collection of servers may serve the same network address, through network address translation or other techniques. A collection of renewal certificates may, in that situation, be maintained in a store until needed, at which time the oldest renewal certificate may be installed to servers having certificates about to expire.
Regardless of the situation, a fresh or renewal certificate is associated to a destination network server at the time it is signed. A destination network server is therefore identified as corresponding to the received signed certificate. After a server is identified the server type is determined, in order to choose the proper method of installation. For example, if the server is serving web pages over the HTTPS protocol, there are a number of possible web server products that might be installed. For example, the Apache web server might dictate that certificates be installed through a file placement to a specified directory, a modification of particular configuration files (especially for non-renewed certificates), and restarting of the web server daemons. In another example, an iPlanet web server might provide a web administrator interface. In that circumstance the text of the certificate might be cut and pasted from an email into a text entry field, following which the web administrator installs the certificate text in the correct location. It may also be necessary to restart the PKI application and/or computer to flush the old certificates out of memory. Installation scripts might be written to support a number of PKI platforms, for example iPlanet, Apache, IIS, Netscape, Websphere in a multiplicity of versions.
In many if not most installation procedures, an authentication step will be required to access the certificate store on the destination device. This may involve offering an administrator username and password, a passphrase, a certificate or other authorization object. An authorization object may be stored within or accessible to the installation system prior to the installation activities.
The installation system has access to installation instructions which constitute a set of installation steps for installing certificates to particular server types. These installation instructions may take many forms, the content of which will depend on the type of interface used to perform the installation steps.
In a first example, the installation instructions define a set of shell commands. An exemplary set of shell commands for installing a certificate to an apache server might be: (1) log onto the destination server using an SSH connection and using a pre-stored username and password, (2) use the "cd" command to change the current directory to the certificate directory store, i.e. "cd/etc/ssl/apache", (3) remove the old certificate, i.e. "rm-f./server.crt", (4) install the new certificate, i.e. "echo MIIDBTCCA . . . >server.crt", (5) install the new private key, i.e. "echo MIICXQ . . . >server.key", (6) restart the web server, i.e. "apachectl restart", and (7) terminate the SSH connection. Now, the directories given above may vary between operating system distributions and even between installations if an administrator has changed the directory configuration from the default. If it is desired to support an expanded range of server configurations, it may be desirable to examine the server configuration files. In the above example, which assumes a default Apache 2.0.47 server installed to a Linux Mandrake 9.1 operating system, the location of the ssl certificate and key can be found using the commands "grep SSLCertificateFile /etc/httpd/conf.d/41_mod_ssl.default-vhost.conf" and "grep SSLCertificateKeyFile /etc/httpd/conf.d/41_mod_ssl.default-vhost.conf", assuming that root access is available. Similar installation instructions may be fashioned through a study of other server products to be supported.
A second installation instructional example utilizes file transfer protocols to deposit the certificate and key to a destination server. This example includes the steps of (1) using the scp protocol to transfer the certificate to the server, i.e. "scp -B server.crt /etc/ssl'server.crt", (2) use the scp protocol to transfer the private key to the server, i.e. "scp -B server.key /etc/ssl/server.crt", and (3) notify the administrator that the server needs to be restarted, for example by an e-mail message. Other file transfer protocols can be used, such as FTP or NFS, however it should be kept in mind that using insecure protocols over public networks may comprimise the security of the destination server.
A third example utilizes a web interface provided with the server application. A web interface is sometimes provided with a web server or other server application, by which control of the operation of the server may be commanded through a web browser. The web interface, if enabled, is accessible typically at a default relative URL, which might be at a special IP port, directory, CGI or other executable web script or program. In this example, the instructions are configured for a program that acts as a web browser, sending input back to the server's web interface as if the input came from a person operating a browser. This exemplary set of instructions includes (1) a command to go to the login URL of the web interface, (2) submit a form to the web interface containing an administrator usemame and password, (3) receiving the resulting web page, (4) a command to go to the certificate entry URL of the web interface, (5) submitting a second form to the web interface containing the new certificate and key, (6) confirming the submission of a new certificate and key in a third form, (7) a command to go to the web interface page including a "restart server" button, and (8) sending a fourth form containing a selection of the "restart server" button.
The third example might be implemented in any number of ways. For example, a PERL script to perform the steps might be written utilizing an http protocol library. In another example, a web scripting language is utilized to provide a shortenend and simplified interaction script. Likewise, any number of scripting or programming languages may be used to provide controlled interaction with a server's web interface.
In a fourth example, an agent may be pre-installed to the destination server. In that example the agent monitors some communication channel for instructions to install certificates and keys. That communication channel might take several forms, such as a TCP/IP connection, an SMTP receiver, an RPC interface, or the agent might periodically review a configuration file located on the destination server or at another location. Likewise XML web service interfaces, web interfaces, and other secure and non-secure layers or custom protocols might also be used. That agent would include support for the server type such that incoming certificates are properly deposited in the correct location. Such an agent may also include authentication measures to prevent unauthorized agent activity. The agent may optionally also cause a restart of the server application or a reboot of the server itself.
A certificate installation system might utilize one or several methods of certificate installation. Such a system might incorporate a table selecting an installation method and/or script to execute depending on the server type, i.e. the server's operating system and server applications installed thereon.
In a fifth related installation, information is first retrieved to effect contacting and install the certificate to the destination web server, accelerator or other device, that information including at least some of the platform type, the operating system, a detault protocol such as telnet, SSH, HTTP, HTTPS, etc., the certificate text, the destination server's IP address or hostname, a user name and password to log onto the destination, a password for the certificate store, the certificate common name, and a port number to initiate contact with the destination. Next, the certificate text is formatted to be in X.506 base 64 encoded format. The destination is then connected to using the port number, IP address and protocol specified. For certain server applications such as the Apache web server, an IBM web server, an IPlanet server or accelerator, the OpenSSL service is started. Next, the command "find / -name ssl.conf", or a similar command, is executed to locate the SSL configuration file. The command "find / -name httpd.conf", or a similar command, is also executed to locate the server configuration file. Next the certificate and key name are extracted from the configuration file using "grep \SSLCertificateFile/" or a similar command. A new configuration file is then generated either including or referencing the new certificate, and written to the destination server. If needed, the "make" command may be executed to roll out the updated certificate information to all server files. The connection is then terminated and the server restarted.
Now in the above examples, a new private key is installed for every new certificate. The use of several keys over a period of time tends to increase the difficulty of discovering the keys, or at least may prevent an attacker from discovering a key while it is in use. The use of new keys is not strictly required, however, and an installation procedure may install a new signed certificate containing an old public key, if desired.
Also in the above examples, no provision is made to reconfigure a server application to support PKI operation. Any of the above examples may be expanded to configure PKI supporting applications, for example by modifying files or accessing a web interface. By reconfiguring a server automatically, a laborious process of configuring servers for SSL or HTTPS support may be avoided.
Provision may also be provided in the certificate installation system for approvals. Upon receipt of a certificate signed by a certificate authority an administrator may be notified, for example by email. The received certificate may be held pending approval by the administrator. The installation system may provide an approval interface, for example accessible by a web browser, by which an administrator may authenticate himself to the system and select certificates approved to be installed. The interface may additionally provide for bulk approvals, i.e. presentation and approval of a group of certificates in a single approval step. The interface may additionally present certificates sorted in order of expiration date or priority, providing for ease of administrator selection. Optionally, certificates may also be presented in order of risk according to certificate risk profiles. Following approval, the certificates may be installed to the appropriate servers, for example using automated processes as suggested above.
An installation and renewal system may also include provisions for monitoring expiring certificates. In such a system, certificates may be enrolled in a certificate watch program. On a periodic basis, for example daily, weekly or monthly, a certificate database is reviewed for certificates expiring within a future period. Finding certificates in need of renewal, a notification may be sent to an administrator, which for example might be by e-mail or by a display upon login at an administrator interface. The administrator may then select certificates to be renewed, upon which a process of certificate renewal may be initiated as described below. Alternatively, the renewal system may be configured to initiate certificate renewal without approval, to prevent late certificate renewal should an administrator be unavailable to approve. If more than one administrator is configured, the renewal system may contact other administrators if first administrators do not timely respond to requests for approval.
In an alternate mode, a renewal system may scan the servers of a network periodically, as in the discovery processes discussed above, to detect certificates due to expire within a future period. In that system certificates might not be enrolled, but rather servers might be enrolled in a server watch list. In another alternate mode, agents are installed to the servers being monitored. Each agent periodically reviews the certificates for expiration, and may notify an administrator or a central system of any certificates about to expire, for example by email.
A manual certificate renewal process is typically initiated at the server to which the certificate will be installed. The process begins first by the generation of a public/private key pair. Now the key pair might be generated externally to the server, but that method introduces some risk of compromise in that the private key could be discovered in the process of moving it to the server. Following the generation of the key pair, a certificate signing request (CSR) is generated, which is basically a partially completed certificate in that it contains the public key and server identification, but is not otherwise associated to a certificate authority or a root certificate. Having a certificate signing request, it may either be sent to a certificate authority or it may be signed in-house. If a certificate is to be used externally, it should either be signed by a certificate authority or by using an intermediate root certificate itself signed by a certificate authority. Certificates to be used for internal use only may be signed by an internally generated root certificate, because those certificates maintained by an organization may be considered to be trusted. The signing process generates and attaches a signature to the certificate, which signature is generally an encrypted hash value generated from an unsigned certificate generated from the CSR information and from other information, such as the location of the root certificate and the validity period, which is encoded by the private key corresponding to a public key of a root certificate. The signed certificate is then ready for installation to the server.
The following method may be useful to generate a certificate signing request remotely using shell commands through an SSH, Telnet or other shell connection. First, the information needed as input to generate the certificate signing request is provided, including at least some of the protocol to be used, an email address, an IP address, the locality of the certificate including the country, state and city, the organization name, a certificate store password, and a port number to initiate a connection with the remote platform. Next, the remote shell is opened to the remote platform, utilizing known usernames and passwords or other authentication means. A command is then executed to set the remote platform to configure mode, followed by a command to enter an SSL configuration utility. The certificate store is then remotely opened and the default SSL certificate selected. Next, the current private key is removed from the certificate store. A new private key, for example a 1024 bit DES key, is generated and placed in the certificate store. A new PEM file or PKCS file is then created using the newly created private key. A further command is then sent to exit the SSL configuration utility. The "gencsr key" command is then used to create a new certificate signing request file with the city, state, country, organization name/unit, common name and email address provided in the earlier input or obtained from default set values. The output of the CSR text between the string identifiers " - - - BEGIN CERTIFICATE REQUEST - - - " and " - - - END CERTIFICATE REQUEST - - - " may then be captured and optionally placed in a database for storage until needed. Housekeeping activities and disconnection may follow the capture of the certificate signing request.
A simplified certificate renewal process is depicted in
The public/private key pair may be generated off the destination server, particularly if the server does not include software to generate the key pair (many operating systems include a well-known product called openssl). If that is done, it may be desirable to ensure the network between the generating computer and the destination is secure to avoid private key discovery.
The submitting a certificate signing request to a certificate authority is typically performed through a network connection over the Internet. The certificate authority (CA) presents an interface, for example in a web browser, in which an administrator may enter the CSR and other information related to the request, such as the requesting entity's identification, account number or a challenge phrase. If desired, the CA may permit the use of default values, in which case it may be possible to initiate a request by submitting only a CSR and identification of the requester. Upon receiving the CSR, the CA may take steps to verify the identity of the requester so as to avoid others from impersonating a proper requester and receiving valid and/or trusted certificates. After a period of time, usually at least several hours but typically not more than a few days, the CA issues the signed certificate. The issuing typically takes the form of sending the issued certificate to the administrator in an e-mail message, although other transference methods might be used equally well.
In other communications with certificate authorities, specialized protocols may be used. One exemplary protocol called the XML Key Management Specification (XKMS), the specification of and description of which is available from the World Wide Web Consortium, may be used as a starting point for a certificate signing request transmission protocol. Web interfaces suitable for human access may also be used through http automation tools. Screen scraping, data manipulation, key stroke automation, mouse click simulation and other forms of automation can be used to interact with such a web interface. Direct socket communication might also be used.
A certificate renewal system may include facilities for automating certificate signing, as will be presently described. As with certificate installation, certificate signing requests may be subject to approval. As expiring certificates are identified, they may be presented to an administrator for renewal. If it is desired to continue use of particular certificates or servers, an administrator may select those for certificate renewal. Approved certificates may be reviewed and parsed for informational items to be recycled, for example the server identity and the owning entity identity. A new certificate signing request is generated, either locally or remotely, for example at the server to receive the certificate. If a CSR is generated locally, the generation uses the identity of the destination server. If desired, the CSR may then be sent to a CSR for signing. Alternatively, if a root or intermediate root certificate is to be used and is available locally, the renewal system may sign and issue the certificate.
If a CSR is submitted to a CA, a period of time will elapse before issuance of the corresponding signed certificate. It may therefore be desirable to suspend the renewal process until the certificate arrives. For interacting with CAs that issue certificates by email, the system may monitor the incoming email messages. If desired, the system may include a specialized SMTP module to receive emails, in the event that an SMTP client isn't provided by the hosting operating system. Alternatively, an email filter may be applied to an existing SMH system to route messages from CAs to a renewal program. Regardless, the renewal system reviews the incoming email messages for issued certificates, and extracts them from the emails as needed. Alternatively, a CA may issue certificate by download. In that event, the renewal system may periodically access the CA's website. Of course, if a certificate is issued locally, for example if a management system is configured to act as a CA, it is immediately available for installation. Once a certificate is received or otherwise available, it may be held pending approval or immediately installed as in the examples above.
The CA may have policy regarding the issuance of certificates, for example declaring how an issued certificate may be used. A certificate renewal system may be fashioned to be not only compatible with the protocol requirements of CAs, but also with any policy requirements set forth.
In an exemplary certificate renewal method, challenge phrases used in the submission of CSRs to CAs are stored in the renewal system privately, and may also be encrypted if further security is desired. If a CA requires the submission of an administrator certificate or other object to accompany the submission of a CSR, those objects may be stored at the renewal system and made accessible for transmission to the CA in accordance with existing protocol. Internal CAs may also be used, i.e. certificate authorities controlled internally by a certificate using entity, for example if public validation of certificates with trusted CAs is not required.
CSRs may also include custom fields, such as accounting codes, group identifiers, usage notations, and other information associated with a particular issuing certificate. In one example, custom fields are included providing accounting codes that may be used to track operational expenses. In another example, usage notations are included in CSRs to provide, encoded in the issuing certificates, instructions where to install the certificates. Many other uses of custom fields may be used as desired, and may be facilitated by a renewal system.
A renewal system may also include access control for users and groups of users. The system may maintain a record of users authorized to view, change, renew and otherwise manage certificates. Authentication may be made through the use of passwords, certificates or other identifying objects. Certificates may be assigned to be managed by a single user or several users. Likewise, user groups may be configured to permit individuals within the user group to manage certificates.
Throughout the renewal and/or installation progress a log may be maintained by the system. The log may track activity at any level of detail desired, which might be in one example programmable. Entries might include logins, logouts, certificates approved for renewal, certificates approved for installation, which certificate authority was used to renew particular certificates, which server a certificate was installed to, which version of automation scripts were used and many other possible events.
If it is desired to use intermediate root certificates to sign end certificates, before creating a CSR an examination of available intermediate root certificates may be performed to ensure the period of validity of the end certificate is within the period of validity of a selected intermediate root certificate. Should an intermediate root certificate expire before the desired end certificate period of validity, or the root certificate become valid after the start of the period of validity of the end certificate, an administrator may be notified of a problem. The administrator may choose to renew the intermediate root certificate, obtain a new intermediate root certificate with an appropriate validity period, defer the renewal of an end certificate, or choose to have a certificate to be renewed signed by a publicly available root certificate.
Likewise, an installation or renewal system may also handle the installation and renewal of intermediate root certificates. In that system, it may be desirable to provide backup for intermediate root certificates and private keys from which those certificates have been generated, so as to prevent the loss of private keys necessitating the obtaining of new intermediate root certificates for issuing new end certificates. A database may also be maintained including information about the relationship of intermediate root certificates and end certificates issued from those root certificates. Other information may be stored in such a database, such as the attributes of intermediate root certificates, which devices contain those certificates, what certificate authorities issued those certificates, a history of end certificates issued from intermediate root certificates, and other related information.
A certificate renewal system or a certificate signing requesting system may make use of a certificate authority abstractor, which permits certificate related interaction with two or more certificate authorities using a common schema of operation. A number of certificate authorities presently make their services available, however each presents a different interface and procedures to administrators who wish to submit certificate signing requests. Thus an administrator may be required to learn the various web pages and/or software interfaces, functions, administrations, reporting and delivery systems of several certificate authorities.
The conceptual elements of a certificate authority abstractor are depicted in
CA abstractor 115 also presents a uniform interface 119 for receiving information pertaining to the submission of an individual certificate signing request 112. Interface 119 provides a uniform set of entries for at least the informational items required in a certificate signing request generally. These entries may provide for such items as a common certificate name, a period of validity, a locality identification, a public key, user defined fields or other fields in many combinations.
In a first exemplary abstractor, the certificate request information contains only a certificate signing request generated externally, for example at the server destined to receive a signed certificate. In a second exemplary abstractor, the certificate request information contains information sufficient to complete a certificate signing request by the CA abstractor using a transferred public key. Many other data transference schemas can be implemented as desired with attention to the details of any larger certificate automation system.
Abstractor 115 further receives a selection of a certificate authority 116, which may occur one time through a default setting, or a CA choice may be presented each time a certificate request information record 112 is submitted. The selection of certificate authority determines which script will be executed and which certificate authority record will be executed. In some circumstances and as shown, the abstractor will interact with one of certificate authorities 118 a or 118 b by way of an external network 117, which may be the Internet. Alternatively, if a locally maintained certificate authority is available, external network 117 may be replaced with an internal network or other communicative objects. Once certificate authority records are received, certificate request records may be submitted to the abstractor, whereby the all required items by the selected certificate authority may be provided. The interaction by the script 114 may then communicate a request that in its totality constitutes a certificate signing request associated with the requesting entity.
In an alternative abstractor the abstractor acts as a proxy application to the true certificate authorities. An administrator or system, for example a certificate renewal system, may interact with the abstractor as if it were a true certificate authority, passing the same informational types using similar interfaces, as desired. Additionally, although interaction with two certificate authorities is shown, the concepts disclosed above may be extended to support operation with any number of certificate authorities.
A certificate installation or renewal system may also perform a verification operation to verify that a newly requested certificate has been installed correctly and is available for use. In an exemplary method, the system may act as a client for the particular service for which the certificate is being used. For example, if a new certificate is for a web server supporting HTTPS, the installation/renewal system may attempt a secure HTTPS connection with the destination server. The verification may include checking for use of the new certificate and general operation of the secure use. Notifications may be sent to an administrator on success or failure, which may be after a timeout period if verification does not immediately follow certificate installation. In an exemplary system, alerts may be sent to more than one administrator, the system contacting further administrators if administrators previously notified haven't resolved a problem. That system may also submit periodic messages, such as what certificates are due for renewal in the near future, for example a period of 14 days.
Presently, it is difficult for enterprises to switch between certificate authorities, as the certificates under use may be expiring at different times and the enterprise may wish to continue to use existing certificate services paid for through the end of that term. In a manual system, as certificates expire an administrator is required to track certificates individually, renewing each certificate with the new authority. This activity can be relatively expensive and is susceptible to error.
In a certificate renewal system, a default certificate authority may be selected. That selected CA may then be used to renew certificates, by transferring information from the old certificates into CSRs to the new selected CA. If desired, a renewal system might also be commanded to replace all or a part of a set of managed certificates, swapping out certificates one or more several undesirable certificate authorities with a selected certificate authority. In an exemplary renewal system a "migrate" function is provided permitting automatic transfer of certificates managed by unsupported certificate authorities to a default certificate authority for which certificate requests are supported.
Systems for Managing Certificates in an Enterprise
A more complete system for managing certificates in an enterprise will include facilities not only for monitoring certificates, but also for requesting renewed certificates and installing those certificates to the enterprise. Another simplified method depicted in
A scanner 57 may be provided to scan the network for certificates to be managed, which in this case would scan any or all of servers 53 a-d, accelerators 54 a and 54 b, and internal CA 60 if provided. Upon finding servers and certificates installed thereon, scanner 57 may provide resulting information to a database 58 containing information identifying certificates, expiration dates, and issuing CAs for the certificates. An installer 56 may also be provided to automate the installation of new certificates on servers 53 a-d or accelerators 54 a and 54 b. Installer 56 may further automate the installation of intermediate root certificates to internal CA 60, if desired. A renewer 55 may be provided to monitor the expiration of certificates of which information is stored in database 58 and may provide functions related to the renewal of expiring certificates. One function is to notify an administrator of an expiring certificate. Another function is to initiate the renewal of a certificate through the automated generation of a certificate signing request, optionally after administrative approval. Another renewal function is the delivery and/or installation of renewed certificates to servers. The system of
Referring now to
The configuration of
An exemplary certificate management computer system is packaged in a rack-mountable form-factor and includes a Pentium 4 processor operating at 1.7 GHz or higher, 512 MB of 400 MHz SD-RAM, a RAID system including two 40 GB hard drives in a data mirroring configuration, redundant power supplies, two redundant 10/100 Base TX network ports, two 9-pin serial ports, one parallel port, four USB ports, and a graphics port supporting VGA video modes and higher. Other computer systems may be utilized in various circumstances, for example if a relatively small number of certificates are to be managed or if network access is provided through a non-Ethernet connection. Likewise, the computer system may have other software installed thereon, provided that sufficient processing power and network resources are provided to handle the total operating loads on the system.
The exemplary certificate manager includes a user interface accessible through the HTTPS protocol, of which FIGS. 15 to 48 are representative. That user interface will now be described.
Referring first to
If an administrator selects to view or edit a server record, a screen similar to that of
In the exemplary certificate manager users may be grouped together to ease the administration of user privileges.
Depicted in
Additionally included in the screens shown in
The CA setup screens may be modifiable by program updates from the seller, manufacturer or licensor to adapt to changes in the operation of the certificate authorities made available for use. Those program updates may also include updates to the scripts (or other programmable elements) used to interact with the certificate authorities intended to be usable to the administrator.
A second exemplary certificate manager may be set up as a replicator for a first manager, providing failover functionality. Shown in
Depicted in
The exemplary certificate manager may also manage intermediate root certificate authorities and intermediate certificate authorities, such as might be the case with a Windows 2003 CA above. The configuration of the intermediate root certificate authority settings for the manager may be controlled in a screen similar to that shown in
The exemplary certificate manager may also scan for intermediate certificates on the discovery network. The manager may discriminate an end certificate from an intermediate root certificate by a review of certificate contents, or the manager may examine the chain of authority for certificates for parents located on the discovery network.
The exemplary certificate manager additionally permits the generation of various reports. Depicted in
Of the reports available, several historical reports may be generated by the exemplary manager. Depicted in
The logs generated by the exemplary manager are also viewable.
Further in the exemplary manager, user roles may be assigned to users. A user may thereby be given authorization to perform various administrative actions, for example authorizing the request of new certificates or merely viewing the certificate database. The exemplary manager may additionally act as a firewall to the management software, permitting communication only to selected ports in the network protocol. For example, a manager might enable port 443 for HTTPS administrative user interface access and port 25 for receiving email in a TCP/IP protocol supporting manager. Providing firewall functionality may prevent attacks from worms, buffer overflow attacks or other attacks, and make make a manager suitable to be connected directly to a public network such as the Internet.
The certificate database of the exemplary certificate manager may additionally be encrypted. Optionally, the manager may generate a self-signed certificate initially to encrypt the database. The self-signed certificate may be protected from user access by user privileges, by encryption with a fixed key, encoding in a non-readable or specialized format, or other method. Private keys used to generate CSRs are not stored on the exemplary manager, but are stored on the destination servers (where they may have been generated by the creation of a CSR).
The exemplary manager may further include an updating tool. The updating tool checks for security or bug fix updates to the system periodically, and downloads and installs any updates automatically. The manager may further include one or more fail-safe mechanisms that run system diagnostics on a periodic basis to gauge the health of the system and attempt error recovery. Administrators may be notified by email if error recovery is unsuccessful. The manager may further include a database backup feature functional to restore and archive the state of the system.
Systems for Managing Digital Certificates to Client Devices
Systems described above permit the automatic maintenance of certificates on server devices of various types. Systems may also be constructed to install and maintain certificates on client devices as well. Referring now to
If the client presents a certificate for authentication, tested in step 1306, the server may proceed to validate the certificate as in step 1308. The server may also test for certificate revocation, for example by comparing the certificate against a list of revoked certificates. If the certificate has been revoked, or if the certificate is not valid for the authentication purposes, tested in step 1310, the server may proceed to issue a new certificate to the client. Proceeding from one of steps 1306 or 1310 to step 1312, the user is authenticated using an alternate procedure, as a valid certificate was not presented. The alternate procedure may take many forms, such as the entry of a known usemame and password, a passphrase, an account number and PIN number, or any other procedure which may identify the user of the device to the satisfaction of the service provider. Alternatively, if it is merely needed to identify the client device upon subsequent accesses, the user authentication need not be performed.
Upon successful alternate authentication, a new certificate is delivered to the client. Under some circumstances it may be desirable to maintain a store of new certificates, to avoid delays in a service due to the time required to issue a new certificate. Alternatively, a new certificate may be created about the time of delivery, which might be created by in internal or external certificate authority entity. Once a new certificate is delivered to a client, transactions may proceed with the client device under an assurance of authentication, as in step 1320.
If in step 1308, the client certificate delivered to the server is found to be valid and not revoked, a check for an expired certificate may be performed in step 1316. If the certificate is not expired, authenticated transactions may proceed in step 1320. Otherwise, a process of renewing a certificate may commence, in step 1318. In that step, the old certificate is renewed with the appropriate certificate authority, which might be internal or external, and the renewed certificate delivered to the client. The renewal of a certificate might occur at the time of the connection attempt by the client, however a small delay may be introduced, especially if an external certificate authority is used. Alternatively, a process may periodically run on the service side, checking issued certificates for expiration. Certificates may be renewed prior to a request for connection for services from a client, avoiding the small delay, provided that the client certificates are stored in the service system.
In the exemplary method described above, agents may be fashioned for particular client devices. Through the method, an installed agent may act to communicate with the service provider to receive certificates therefrom. An agent may also, if desired, provide an interface for presenting certificates to the service provider. An agent may also provide for management of client certificates in a local store, if local client facilities are not provided or not used otherwise. An agent may, if desired, remove managed certificates from a client device at the time the agent is uninstalled. The agent might also be fashioned to be more comprehensive in function, and may manage a session or transactions with the service provider.
Agents may be fashioned for several kinds of client devices. For example, an agent might be fashioned as a background executable process or daemon communicating with a service provider on a selected TCP port, executables being provided for a number of operating system types such as WinCE, PalmOS, PocketPC, Windows XP, MacOS, Linux, etc. In another example, an agent might be downloaded from the service provider about the time the request for connection for services is made. That agent might be written in a platform-independent interpretive language, such as Java, or might be an executable program provided by a server based on the perceived client type. In that example, the agent might only reside on the client for a fixed period, although the client certificates may reside at the client locally. In another example, the agent might be a browser plugin, which may be automatically downloaded from a predefined location at the time a user first attempts to access a service provider. In yet a further example, an operating system may provide access services sufficient to perform the agent functions, in which case the operating system may be equivalent to a certificate agent.
As to a client certificate, a client may be identified in several different ways. In a first example, a client certificate contains an encrypted identifier assigned by the service provider, the encryption performed with a secret key known to the service provider but not by others generally. The identifier may be associated with an individual's service, for example a bank account number or a user identifier for an information subscription service. The encrypted identifier might include a user identifier and a passphrase, for example a usemame and password or an account number and PIN number.
The identification data may not necessarily be kept secret. For example, if a service provider is in the business of providing access to databases and literature for a fee, the impact of discovery or monitoring the activities of the user might be negligible, although it may be desirable for the service provider to ensure that the user is subscribed. In that example, a certificate might contain a subscription number digitally signed by a key maintained by the provider.
Now in the above client certificate management methods the service provider may identify the individual or group using the service using a presumption that other individuals will not be permitted access to the client device. For example, if the client device is a personal data assistant (PDA), it may be presumed that that device is for a particular individual only, which individual will retain control of to prevent unauthorized use of the service provider's services. If that assumption is made, a service provider may authenticate using a certificate on a client device alone, and need not require the entry of passwords or other user authenticating items.
The service provider may also wish to prevent the transfer of a certificate from one client device to another. In that case, the certificate may include information unique to the client device, for example a MAC address, a fixed IP address, a serial number or a processor ID. The signature of the certificate may further be obtained by encoding the unique information, causing a signature mismatch should the certificate be moved. In an alternative system, an agent may provide the unique information to the service provider so as to avoid an unauthorized user masquerading a different client device for the original device.
Referring now to
An agent server 1414 may also be provided to assist with the download and installation of agents to clients. An internal certificate authority 1416 may be provided to produce encryption/decryption keys or facilities for digitally signing certificates. In one example, internal certificate authority 1416 is in communicative proximity to service provider 1408 so as to avoid substantial delays in data processing. Optionally, an external certificate authority 1418 may be used, which may be operated independently of the entity operating the service provider 1408. If an external certificate authority is used, a certificate may be used to sign user transactions which are afterward publicly verifiable. A certificate store 1402 is provided at client 1400 to store certificates issued by the service provider, making them available in later accesses between client 1400 and service provider 1408.
Now it is to be understood that service provider 1408, optional certificate store 1410, revoked certificate database 1412, agent server 1414 and internal certificate authority 1416 might be completely separate computing systems connected by a network. Alternatively, elements of those may be combined as desired on shared computing resources. In another example, not shown, each of service provider 1408, certificate store 1410, revoked certificate database, agent server 1414 are elements residing on a single server or distributed servers, with internal certificate authority 1416 being optionally included thereon. The operation of a system according to the principles set forth above is illustrated in
Referring now to
In the exemplary service, each client device may be assigned trust levels, the selection of which is shown in
Depicted in
Depicted in
Depicted in
In the exemplary client authorization system above may provide for authentication of a user under the requirements that (1) the user is using a device made trusted earlier and (2) for transactions considered highly sensitive, that a usemame and password or other higher form of authentication be used. In the exemplary system above, it may not be necessary for a user to manage digital certificates, enrollments or digital signing dialogs, although the client system may provide for such activities for advanced use. Also in that system, a global certificate may be provided by the system to various service providers to sign online transactions, or several certificates may be created and stored at the client for signing transactions for several service providers. The exemplary system may also require confirmation by return email to add or remove a client device from the registration list. Additionally, an intruder must not only obtain a usemame and password to create a fraudulent transaction, but must also perform his actions from one of the registered client devices. This makes fraudulent activity much more difficult to accomplish than with present systems that rely only on a usemame and password for user identification.
Now although examples above may have included servers utilizing SSL or TLS protocols, the examples above may be modified as will be understood by those skilled in the art to encompass other protocols, such as message queuing systems, VPN systems, S/MIME systems, IPsec systems, code signatures, 802.11x EAP devices, encrypting file systems (EFS), and client web authenticators, as well as other server types and protocols. Likewise, the above examples have referenced web servers utilizing digital certificate. Those examples may also be modified to include other server types such as application servers, databases, SSL offloading devices, SSL accelerators, or any other type of server or device having the ability to utilize an SSL certificate to communicate securely over a network connection. The above examples have also made use of SSL certificates. Other types of certificates of varying formats and protocols may also be used in the above disclosed systems with minor modification to operate with virtually any conceivable public key infrastructure.
While a number of digital certificate discovery and management systems have been described and illustrated in conjunction with a number of specific configurations and methods, those skilled in the art will appreciate that variations and modifications may be made without departing from the principles herein illustrated, described, and claimed. The present invention, as defined by the appended claims, may be embodied in other specific forms without departing from its spirit or essential characteristics. The configurations described herein are to be considered in all respects as only illustrative, and not restrictive. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Appendix A
The following is a list of possible error codes, descriptions, and suggested resolutions.
Patent Citations
Referenced by
Legal Events
Original Image


text:
Newbies, Post in Welcome Central to open up the boards
0 Members and 1 Guest are viewing this topic.
I'm glad you're no longer in rehab
His eyes don't bug out as much since rehab. Just kidding Dad. Wow! I'm guna' pay for that one.
Wow! I've only been back here on this board less than 48 hours and I already gained a child and then lost it without lifting a finger.

subset: commoncrawl


text:
Monday, January 14, 2013
The Green Wave wrestling team brought home the Cane Bay Duals championship Saturday.
Nearly 20 varsity teams competed in the fourth annual tournament held at Cane Bay High School. Summerville went 5-0 in the tournament and claimed the championship with a 42-30 win over Hanahan in the finals.
The Wave advanced to the finals by defeating Carolina Forest 56-12, Bamberg 51-29, Wando 56-16 and Beaufort 43-30.
I think we wrestled well and I am pleased to have won with the quality of schools that were represented at the Cane Bay Duals, Summerville coach Darryl Tucker said. It was a good measuring stick but its still early in the season. There are a lot of lineups that will look differently in January and February.
Summervilles Dylan Wyman, Tyler Fachko, Gavin Perkins, Daniel Smith, Chad Wood, Kyle Sullivan and Trey Privette were all undefeated during the tournament.
Beaufort defeated Stratford in the third-place match. Cane Bay finished in fifth place in the tournament after winning a tiebreaker with Wando on the most first takedowns criteria.
Summerville, Beaufort, Stratford, Wando and Cane Bay are all ranked among the states Top 20 Class AAAA teams. Hanahan entered the season ranked second among the states Class AAA teams.
The Journal Scene is pleased to offer readers the enhanced ability to comment on stories. We expect our readers to engage in lively, yet civil discourse. We do not edit user submitted statements and we cannot promise that readers will not occasionally find offensive or inaccurate comments posted in the comments area. Responsibility for the statements posted lies with the person submitting the comment, not The Journal Scene.
If you find a comment that is objectionable, please click "report abuse" and we will review it for possible removal. Please be reminded, however, that in accordance with our Terms of Use and federal law, we are under no obligation to remove any third party comments posted on our website. Read our full terms and conditions.
© 2015 The Journal Scene an Evening Post Industries company. All Rights Reserved.
Registration on or use of this site constitutes acceptance of our Terms of Service, Privacy Policy and Parental Consent Form.


text:
June 17, 2012 (OCALA, Fla.) - Heading to the final round of the Florida Karting Championship Series (FKCS), the Ocala Gran Prix (OGP) race team will be looking to take care of some unfinished business at the ultra fast 103rd Street Motorsports Complex. Taking place in Jacksonville, Florida, multiple team drivers will be taking a run at class championships as they look to build momentum towards the second half of the 2012 racing season.
"It has been a great FKCS season and we are looking to finish it off strong," expressed Ocala Gran Prix Owner and President Jorge Arellano. "While the goal of winning is first priority under the team tent, we will continue to scout for potential sponsored drivers for the 2013 season as well as continue the OGP Pit Stop program. It is going to be a very busy weekend."
It is guaranteed that an Ocala Gran Prix driver will claim the TaG Senior and Rotax Senior championships as five team drivers occupy the first five positions in the series point standings in the TaG division while they stand tall in the top four positions in Rotax Senior. Leading the way in both title chases is multi-time karting champion Nick Neri as he has been the class of the field in both categories, taking seven of a possible ten victories so far this season. With consistent results in the top five, Jonathon Kotyk enters the final round in the second position while Andrew Evans, Brandon Salyer and Annie Hayden round out the top five.
Rotax Senior will see Neri enter the final round as the point leader as Evans and Kotyk swap the second and third position in the points battle. Salyer holds station in the fourth position while Hayden, with troubles at one event, sits down in the seventh position. With Neri claiming seven of ten victories, Andrew Evans has stood atop the box twice while Kotyk added another win to keep all main event victories in the two senior divisions within Ocala Gran Prix.
With Neri poised to take the senior titles, Florida Winter Tour champion Oliver Askew looks like he will be the man to beat in the junior categories. Currently leading both the Rotax Junior and TaG Junior championships, it will take a miracle for him to falter. With Askew claiming five victories in the first ten events and only finishing off the podium once, he will look to continue his winning ways in Jacksonville.
John Dalton looks to have the championship in hand in the TaG Heavy category while Jerry Brown will battle hard in northern Florida to maintain a top five position in the championship. Dalton and Jason Heffner will also see action in the TaG Masters class as they currently sit third and fourth in the championship chase. All the Masters drivers will be back behind the wheel of their Tony Karts in Rotax Masters as they look to end the season on a high note. With the championship already over, all three competitors will be looking to stand atop the podium in the final event weekend of the series.
Floridian Mathias Ramirez will have a shot at three championships in the final event weekend, as he will look to add to his racing resume. Atop the points in Rotax Mini Max and sitting second in Yamaha Junior Sportsman, Ramirez will have a challenge in the TaG Cadet class as he currently sits in the fourth position. Fighting for race wins in the Cadet Junior Sportsman class, Ramirez, along with Dylan Gennaro and Jake Knepper will all be back behind the wheel. Gennaro and Knepper along with Jordan Heffner will also see action in the Rotax Micro Max division as they sit fourth, ninth and 13th respectively in the point standings. Along with Ramirez fighting for the title in Yamaha Junior Sportsman, Dylan Gennaro will also throw his hat in the mix as he sits third in the championship battle and is currently having his best racing season to date.
A quartet of Ocala Gran Prix competitors will enter the TaG Cadet division, as Olivier Bellanger, Aaron Bass and Koleton Mitchell will all join Raimirez in ultra competitive class. Bellanger, who currently sits third in the chase for the title, has the best shot at the championship while Ramirez is right on the door step in fourth. Bass and Mitchell will be working hard to solidify solid results and finish the season in the top ten in points. Ramirez, Bellanger, Mitchell and Bass will all joining Mikey Hornborg in the Rotax Mini Max division. Hornborg, who has steadily improved from an incident in February that sidelined him for a couple months, scored his best outing of the season this past weekend at the North Florida Rotax Max Challenge program at Ocala Gran Prix.
Joining Askew in the Rotax and TaG Junior classes are Florida front-runners Brian Lockwood and Alex Hornborg. While both drivers competed well throughout the season, the duo will be looking to finish the season off strong and move forward in the championship battle. Hornborg currently sits a solid third in the TaG Junior class with Lockwood in the eighth position. In Rotax Junior, both drivers improved their position and sit second and sixth respectively.
Ashley Rogero, a World Karting Association (WKA) Manufacturer's Cup multi-time winner and champion continues to use the FKCS program for championship transfer points. Sitting second in both the Yamaha Junior and KPP Junior point's battles, Rogero missed the first event of the season but has scored more wins than any other driver in the class. With a strong showing in Jacksonville, Rogero will add another pair of titles to her records.


text:
Questions & Answers
Do you have questions about this product?
Get answers from real customers and in-house experts with AnswerBox.
Q:Can I double this as a shampoo as well as using it as a shower gel? Or will it cause issues with my hair?Asked on 5/6/2014 by Endlessly from Minnesota
1 answer
A:Yes, you can definitely use Flying Fox as a shampoo in addition to using it as a shower gel. All of our shower gels double as both!Answered on 5/7/2014 by Melissa S from LUSH Direct
Q:what other products smell similar to the flying fox shower gel????Asked on 12/15/2013 by tootie from upland, ca
3 answers
A:The dominant scent in Flying Fox is the Jasmine, so other products that have a strong Jasmine note as well would be our Lust line of products, Godiva shampoo bar, Tender is the Night massage bar, Lustre dusting powder, and our Sikkim Girls perfume.Answered on 2/26/2014 by Kendra M from LUSH Direct
A:Godiva shampoo bar and Lust perfume have the same scent.Answered on 12/15/2013 by Anonymous
A:Anything with Lust in the title: the perfume and bar soap. Also, Jasmine
and Henna Fluff Eaze smells similar to me:)Answered on 12/15/2013 by Anonymous
Q:how long until flying fox shower gel expires?Asked on 9/20/2012 by erika from glendale
1 answer
A:Flying Fox shower gel has a 14 month shelf life. There will be a sticker on the back of each bottle indicating when it was made, and who made it, as well as when it is best used by.Answered on 10/26/2012 by Megan from LUSH
Q:Which other LUSH product does Flying Fox smell most similar to?Asked on 7/16/2012 by Ivy the Kinski
1 answer
A:I find that Flying Fox smells very similar to the Lust perfume range of products. Loads of sexy jasmine!Answered on 8/28/2012 by Megan from LUSH Direct
Q:is this product safe for use during pregnancy either as a shower gel or bath?Asked on 2/25/2012 by Anonymous
2 answers
A:Our products should be fine to use during pregnancy provided there aren't any unique circumstances or complications. If you are at all concerned, the full ingredients list is provided above so you can verify with your physician to be sure the product is right for your individual needs.Answered on 2/27/2012 by Megan from LUSH
A:Yes. As long as you use it externally. It does not contain any ingredients that may harm your unborn baby. If you use this product to wash your lady bits, wash only externally. Don't wash the inner part with anything, even if it is vegan, organic, or 100% natural. Washing the inside will up the risk of infections.Answered on 5/8/2012 by Andi from Sacramento, CA


text:
Quick Links
Shop All Jewelry
BRZ10299 In Stock
The delicate beauty of our Rose Gold Vermeil CZ Sideways Cross Bracelet will take your breath away. The centerpiece of this gorgeous rose gold bracelet is a unique sideways cross, accented with an array of sparkling cubic zirconias. Weighing a feather-like 1.2 grams, this bracelet will add a stunning accent to your outfit while remaining incredibly comfortable. It can be adjusted from 6.5 to 7 inches long, and fastens securely with a spring-ring for a look to cherish.
Eve's Addiction.com wants you to be a happy customer. We want you to be completely satisfied with the sterling silver jewelry that you receive from us, as we only sell high quality silver and cubic zirconia cz jewelry. We do understand that you may not like your purchase for some reason.
You may return or exchange your jewelry within 60 days of purchase if you are not satisfied with it. The jewelry must be returned in its original condition for a refund or exchange. Engraved, personalized, photo, monogram, name and initial, chocolate and clearance items are not returnable or exchangeable.


text:
DO YOU WANT TO MAKE MR. WALKEN CRY BY NOT ACCEPTING HIM? DO YOU??? - Matty Malaprop
Meme of the Day: Prince Charles Being Attacked by Things
Wake Up Call of the Day: This High Voltage Ejector Bed Will ...
Poly Bridge Proves That Most of Us Shouldn't Be Civil Engineers
The Greatest GIFs of the Week
This is a Parent
If You Got It, Flaunt It, Robin
Emergency of the Day: Man Calls Police Because a Cat Ate ...
Schwarzenegger of the Day: Arnold Has a Message for Lion ...
These Grandparents Are More Savvy Than You Think
Cat Got Spooked
Pick Your Site Name
Tell us more about it


text:
I have this thing about plum tone reds, or purple or plum toned anything really, so I had to get this and I most definitely wasn't disappointed. This is a wonderfully rich color and definitely holds up to its title of moisturizing, which is a real plus in my book.
4 out of 4 users found this review helpful
Was this review helpful? Yes No
MAC Lush Life Mineralize Rich Lipstick ($22.00 for 0.14 oz.) is described as a "deep cool plum." It's a reddish berry with a soft sheen. I really thought it seemed similar to MAC Rebel, but applied, Rebel is purpler and deeper–it looks richer, in a way, on, because of the depth in color (if you own Rebel, pat on a little balm on top, and you'll get this, though). Illamasqua Magnetism is a bit more muted, less red. Guerlain Guet-Apens is darker, more berry-hued. NARS Afghan Red is more subdued.


text:
Wednesday, December 18, 2013
Bishop England senior center Mary Harriet Moore joined the 1,000-point club Tuesday as the Lady Bishops topped the Academic Magnet Raptors 70-44 in North Charleston.
Moore entered the game needing just five points to crack the career milestone. The four-year starter finished with 13, surpassing 1,000 in the second quarter with the Bishops already holding a commanding lead.
It felt awesome, Moore said. I knew that I needed five points at the beginning of the game but I just let it happen.
Moore joins Bishops guard Michele Boykin on the prestigious 1000-point list. Boykin achieved the feat just three games prior.
That just tells you what kind of talents those two are, Bishop England head coach Paul Runey said. You always preach the team concept but it is important to have individual goals. Mary Harriet has been a big part of our success the past four years. Shes a great athlete, has good touch and has been a good ambassador for Bishop England.
Runey described Moore as the best shot blocker hes had in 28 years and praised her selflessness on the court. Moore says the accomplishment ranks high on her list but added that winning state championships as a team trumps any personal achievement.
Sometimes I wish she was actually more selfish because shes that good of a player but thats not what type of person she is, Runey said. These girls do sacrifice a lot of personal awards because they realize its a team game and they want to see everyone on the team do well.
The Lady Bishops (6-0) are doing about as well as could be asked so far this season with lopsided wins in all six games. Bishop England will host the Carolina Invitational Tournament, beginning Dec. 27. The 64-team field features some of the top girls talent from across the Southeast.
Its no slight to the teams weve played but I think this tournament will be a good indicator of where we are and where we need to be, Runey said. Were going to be playing some really good talent. Well need our team to really play well and players like Mary Harriet and Michele to play a big role if we want to have success in that tournament and have another chance at a state championship later in the year.
Moultrie News is pleased to offer readers the enhanced ability to comment on stories. We expect our readers to engage in lively, yet civil discourse. We do not edit user submitted statements and we cannot promise that readers will not occasionally find offensive or inaccurate comments posted in the comments area. Responsibility for the statements posted lies with the person submitting the comment, not Moultrie News.
If you find a comment that is objectionable, please click "report abuse" and we will review it for possible removal. Please be reminded, however, that in accordance with our Terms of Use and federal law, we are under no obligation to remove any third party comments posted on our website. Read our full terms and conditions.
© 2015 Moultrie News an Evening Post Industries company. All Rights Reserved.
Registration on or use of this site constitutes acceptance of our Terms of Service, Privacy Policy and Parental Consent Form.


text:
All was calm after two cars crashed Saturday morning on Ashley Phosphate Road in North Charleston.
"No one's hurt," a 911 caller told a dispatcher. "It was just a T-bone."
Police officers and firefighters arrived to make sure no one was seriously injured. They intended to direct the removal of a disabled car from the traffic lanes.
Then, young women screamed. Some cried. Police officers yelled.
"We need more units!" a police officer barked into his radio. "Send another EMS. We have another wreck! One firefighter down! Two females down!"
Fifteen minutes after the first collision, the police said a drunken man in a Honda tried to avoid a firetruck meant to protect first-responders by veering into oncoming traffic lanes. The man didn't have a driver's license, insurance or documents indicating that he was in the country legally.
His Honda hit two firefighters, three 18-year-old women and one girl. Three people were seriously injured, including Darin Kingery, a 12-year veteran of the North Charleston Fire Department.
Police communications, video and a report released Monday revealed new details about the wreck that prompted the arrest of 26-year-old Felix Garcia-Romero of Hawthorne Drive.
He faces three counts of felony driving under the influence. Experts sampled his blood, but the police did not indicate any test results.
Garcia-Romero remained behind bars Monday in lieu of $300,000 bail. U.S. Immigration and Customs Enforcement also asked that he be held at the jail as the agency investigated his legal status.
It was Garcia-Romero's first arrest in South Carolina.
An attempt to contact his family was unsuccessful. Two hard hats, a pair of work boots, three carpenter levels, tubes of caulking and 5-gallon buckets sat on the front porch of his mobile home.
Kingery, the fire engineer, remained in intensive care Monday after suffering several broken bones, department spokeswoman Bianca Sancic said. Firefighter Joshua Sader, who has been on the job for six months, was treated for minor injuries that day and later returned to work.
Conditions of the other four victims were not immediately known. At least one suffered a broken leg. The 18-year-olds were identified as Areriel Hayward of North Charleston, Abagail Wedlake of Mount Pleasant and Shateia Ellis of North Charleston.
Authorities responded to the first wreck between a Mazda 626 and a Chevrolet Impala at 1:44 a.m. near the Plantation Road intersection.
The Chevrolet blocked two lanes and part of the third.
An airbag had deployed in one car, and one person was complaining of arm pain. But the crash was minor.
"Everybody's out and about," a 911 caller said. "One lady is sleeping in the back."
Fire crews placed a truck in a "defensive" position to help protect themselves, the police and motorists, the department spokesman said. They also wore reflective vests, a protocol to prevent a second crash, Sancic said.
But soon after, Garcia-Romero's black Honda left the northbound lanes and plowed into the disabled Chevrolet and the people standing next to it.
The police scrambled to block traffic altogether and prevent further mayhem.
"We need everyone to just shut down Ashley Phosphate," an officer radioed to others. "We need both ways shut down for safety."
Officers quickly suspected that Garcia-Romero had been drinking.
A video from a police cruiser shows officers pulling him from the Honda. He smelled of alcohol, and his eyes were red, the police noted in an incident report.
Officer Jonathan Lawrence walked him in front of the cruiser's camera, and Garcia-Romero stumbled. He fidgeted through the pockets of his jeans.
"How much have you had to drink?" Lawrence said.
"Two beer," Garcia-Romero said.
"Two beers?" Lawrence said.
Thirty-eight seconds after Garcia-Romero got out of his car, Lawrence cuffed his hands and read him his rights. Again losing his balance, Garcia-Romero leaned back on the officer as he was being handcuffed.
He sat down in the back of the patrol car as the crash victims continued to scream and cry, the video shows.
He mumbled words in Spanish and vomited on himself.
Reach Andrew Knapp at 937-5414 or twitter.com/offlede.
Felix Garcia-Romero faces three felony DUI charges.×
Darin Kingery, a 12-year veteran of the North Charleston Fire Department, was seriously hurt.×
Notice about comments:
The Post and Courier is pleased to offer readers the enhanced ability to comment on stories. Some of the comments may be reprinted elsewhere in the site or in the newspaper. We ask that you refrain from profanity, hate speech, personal comments and remarks that are off point.
We do not edit user submitted statements and we cannot promise that readers will not occasionally find offensive or inaccurate comments posted in the comments area. If you find a comment that is objectionable, please click the X that appears in the upper right corner when you hover over a comment. This will send the comment to Facebook for review. Please be reminded, however, that in accordance with our Terms of Use and federal law, we are under no obligation to remove any third party comments posted on our website. Read our full terms and conditions.


text:
Mucho bueno!
Summer Glau and iPhone 4 in Esquire
Summer Glau did a swimsuit photo shoot for Esquire and in the companion video, busts out an iPhone 4 to take some front-facing pics and to answer a call. We don't post a lot of celebrity iPhone sightings here on TiPb because, frankly, there are far too many to post (and we don't have CrackBerry's eagle eye for them anyway) but when that celebrity is also from Firefly and Terminator... well, that too much geekdom to pass up.
Check out the (Flash! Blame Esquire! Get Skyfire!) video after the break!
[Esquire, thanks browncoat!]
Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!
Reader comments
Summer Glau and iPhone 4 in Esquire
Here is a Youtube link to the photoshoot :
The beautiful and talented Summer Glau is on the FHM Magazine UK (May 2011)
Source : http://summerglauwiki.com/news/summerglauonthefhmmagazineukmay2011/2011-03-02-142
Nice body, sexy feet (although not in that particular shot..odd), but the face is a little underwhelming. Not that I'd say no....
She was also in Doll House, very nerdy.
Uh no. You're thinking Eliza Dushku. Summer was in firefly, the movie Serenity and Sarah Conner chronicles. She also had a guest appearance in Big Bang Theory.
Well, she was never a main character. Guest.
watch out - she'll terminate you with her looks...
We're doing our best to.
Nice, just the video i needed to see, a hot nerd girl named summer, on the beach. While its snowing outside and cold as heck.
This is why I cant wait for "summer" to come again.
I love it when it warm outside, I hate the winter, I love the summer.
PLUS they need to put out one more season of Sarah Connor Chronicles, I really enjoyed that show.
Chrome-Artie FTW !! hahahah.
Plus the singer chick from Garbage, she was cool too.
Can you imagine actually being able to watch the video on your phone?
Mmm, that's nice.......
The T-Mobile girl looks much prettier (Carly)... Also, Rene, aren't you gay? You look very feminine to me...
Why was g-a-y bleeped out?
lmao ew at some of these comment from men but i know of her. Pretty girl
That's awesome. We got an iPhone repair order for a famous model who found us online. Since then she has been recommending our iPhone Repair service to her other famous friends. The funny thing is they call us and name drop her name. We think it's great that they give her name, as if their name didn't carry any weight.
MyiPhone Repair - Nationwide repairs for one Flat Rate and we pay shipping both ways!


text:
Buy with confidence
- Money-back Guarantee
- Free shipping on orders $99 and up
- Superb Customer Service
More from Erbaviva
Completely nourishing and thoughtfully made with the highest quality natural emulsifiers and organic essential oils. Erbaviva Baby Cream moisturizes tender and sensitive skin with its super-clean and luxuriant blend of premium ingredients including aloe, shea and cocoa butters. Soothingly scented with Erbaviva's custom blend of organic lavender and chamomile essential oils. A purely perfect formula for body and face on both baby and sensitive adults. Freshly made with loving care at a facility in Southern California, USA.
"After toweling her off, I use another new favorite product: Erbaviva's luxurious baby cream, to give her a little massage before bed. Soft, clean, flake-free and smelling divine, she's ready for bed. By the way, the company makes great bath and beauty products for moms, too. If only I had time for mommy spa time!"


text:
This collection of short videos, articles and checklists by lynda.com authors is designed to be a "starter kit" covering the key questions you'll need to answer as you design an effective business plan.
Our expert instructors teach you how to manage your time, build your business, and develop your employees. Learn how to work more effectively with tools like Excel, Word, Outlook, Sharepoint, and with operating systems like Windows 8 and Mac OSX.
"I've already been in consideration for a position I've recently interviewed for based on the Access training I've taken the last week or so. Awesome!" —David P.
more from our members »
"In a way, I feel like you are rooting for me. Like you are really invested in my experience, and want me to get as much out of these courses as possible this is the best place to start on your journey to learning new material."— Nadine H.
Thanks for signing up.
We'll send you a confirmation email shortly.
Sign up and receive emails about lynda.com and our online training library:
Here's our privacy policy with more details about how we handle your information.
Keep up with news, tips, and latest courses with emails from lynda.com.
We've updated our terms and conditions (now called terms of service).Go Review and accept our updated terms of service.