Sixscape Certificate Manager is not an online service that provides digital certificates to the public, like DigiCert, it is a product that can be deployed on-premises or in the Cloud (AWS) by an organization to provide in-house certs. Typical uses are:

• Government agency, corporation or E-commerce site or Financial institution issuing client certs (soft token or hard token) for strong authentication to their website (replace username/password authentication wit cryptographic authentication)
• Corporation issuing smartcards to employees for Windows Smartcard Logon
• Any organization providing IPsec certificates for mutual authentication in VPN links (either network-to-network links or road-warrior model), as replacement for “shared secret” deployment
• Any organization providing XMPP S/MIME certs for secure chat within a closed group

The certificates issued by Sixscape Certificate Manager are private hierarchy, which means that the root cert of the hierarchy is not published in all browsers or operating systems, like the root for DigiCert. Getting a hierarchy root published like that is a long, difficult process that involves very complex and expensive security procedures and operations, as well as approval by WebTrust. In theory someone could put up a public hierarchy CA with Sixscape Certificate Manager as the software, but no one has done so to date.

All users (“relying parties”) of certificates from a private hierarchy (servers and clients) must install the “CA Certs” (root and intermediate cert) of that hierarchy. This is not unique to Sixscape Certificate Manager, but is true of any CA that has not obtained WebTrust certification. It is not difficult to install these certs, and they can be published online, distributed via network tools, sent via E-mail, etc. Once the CA certs have been installed on a node, all certs in that certificate hierarchy are trusted by that node. Because of this, you should be careful about installing root certs. Windows will warn you when you try to do this with the following message:

Architecture

Unlike most CA products and services, Sixscape Certificate Manager is not web based. It is a Client/Server design using our Identity Registration Protocol. Web technologies, especially HTTP, HTML and browsers have many security vulnerabilities, hence are not a good choice for a Certificate Authority, which must be highly secure. Today, most people use a browser mechanism to request a certificate and retrieve the signed certificate. There are many problems with this approach:

• In closed-source browsers (like IE) there is no way to verify how the key material (public and private keys) are created. There could be a back-door or weakened algorithms involved, making it possible for certain agencies to crack any security system using those certificates.
• The HTTP connections could be compromised by various hacking attacks, during certificate request or certificate retrieval. The CSR is digitally signed by the private key for that request, but in theory a hacker could obtain the private key, modify the request and sign it again (and the verification would not be able to tell any tampering had been done)
• Most browsers have limited support for advanced cryptographic algorithms, such as alternative symmetric key algorithms like ECDSA,  alternative symmetric key algorithms like Camellia, or alternative hash algorithms like SHA-3.
• No browsers have a simple way to request or work with dual key pairs (one certificate and private key for encryption and another for digital signatures).

Our client/server design can handle all of these easily, and has includes user authentication to the CA (even SCA once your have a client cert). We provide a general purpose IRP client (SixWallet), but all of our apps support automated certificate management via IRP. We provide IRP APIs for other software or product vendors to embed fully automated certificate management in their products. Contact us for details. CAs implemented as web apps are very difficult to implement and extend. Our design consists of native applications and daemons, based on a powerful database engine (currently PostgreSQL). The database can be implemented on the same machine as the CA server, or external (even in redundant clusters for HA). On request we can provide support for other DBMs.

We can provide the schema for our DB on request, to allow you to integrate our functionality into more complex systems. All sensitive information (passwords, passphrases, PKCS12 files, etc) are encrypted. For example, you could produce any arbitrary report needed if our current reports are not sufficient.

Certificate Manager is not Open Source. While Open Source has many advantages, it is a poor choice for CAs since hackers have access to the entire source code to find vulnerabilities to exploit, and may even be able to commit changes and extensions that could compromise the CA. Certificate Manager was designed and implemented in-house by industry experts and the source code is not available to hackers. The code is available for proctored review by large customers on request. The current implementation is in C#.Net on Windows Server. We are working on a next generation version that will be more scalable, with HA (High Accessibility) in ANSI C (on hardened FreeBSD). This version will be sold as an appliance or a hardened cloud image.

Certificate Manager includes support for Certificate Revocation List (CRL) generation and publishing (via HTTP and/or LDAP). It also includes an Online Certificate Status Protocol (OCSP) server. For legacy devices that don’t support IRP yet, we include a  (SCEP) server. These are the only components in Certificate Manager that involve HTTP (we can’t avoid it here, the specifications require implementation over HTTP and many relying applications use these functions over HTTP).

Automation

Certificate Manager has fully automated Registration Authority (RA) function. The default auto-RA component approves all requests (this assumes that all requests have been reviewed and approved externally, e.g. by a bank agent requesting certificates for its customers when an account is being set up). We can provide the source code to this module for you to base approval on any criteria (e.g. information in a customer or employee database). It also has a fully automated Certification Authority (CA) function. Once a CSR is approved by the RA, this module can automatically create the signed certificate from the CSR, using prefconfigured algorithms, validity periods, etc. Again, source code is available to this module on request. We can even fully automate creation of user accounts from a DB or LDAP server (since we have authentication in IRP, a user account is required for each user, unlike most CAs).

Deployment

Sixscape Certificate Manager can be deployed on any hardware server that supports Windows Server 2012 R2 or later. It can also be deployed in AWS with full dual stack access (we can provide it in AWS AMI format, ready to deploy). We are working on a hardened version based on FreeBSD that can be sold as a hardware appliance or AWS AMI image. That version will have high availability, continual database replication, auto dual stack failover,  etc. We can also provide access to a hosted deployment (SaaS) run by a strategic partner for those who prefer not to deploy or manage their own Certificate Authority.

Certifications

We are working on Common Criteria (primarily for the appliance version). We are also implementing ISO 27001:2103 for the company at present.

If your organization requires Common Criteria today, we can work with you to deploy an existing CC certified CA, with our client/server architecture (IRP server) grafted onto it. We can add IRP to any existing CA, so long as we can submit a CSR to it and retrieve the signed certificate from it via protocol (e.g. Restful API).

Distributed PKI Function

What a bank is interested in is not your name and passport, but your identity as their customer. An employer is interested in your identity as one of their employees. Vetting name and address by an online CA is very expensive (e.g. $150 per applicant). Even then it may not be of value to a bank or employer. They need to verify you as a customer or an employee of theirs. Only they have the databases to verify that information.

You can deploy as many copies of Certificate Manager as you want, one per Internet domain (or subdomain, e.g. sg.sixscape.net, aws.sixscape.net, etc). Each certificate contains information needed to access the Certificate Server that issued that certificate (to determine revocation status, obtain CA certs, etc). Each instance can have its own root cert, or can chain up to an external root cert. You can easily deploy a single (highly secured) root CA, and any number of subsidiary CAs that chain up to that root.

Because of this, information vetting can be done by the people in the best position to do it. It can also handle far larger volumes of certificates by distributing the PKI function, rather than trying to have a single giant CA issue and manage certificates for the entire world. Imagine a DNS server trying to provide address resolution for everyone. The volume of server certs is small enough for one centralized CA to handle. Client cert volume is simple too massive for one central CA to handle.

Implementation

Currently, SixWallet is implemented only for Windows (in C#.Net). We will soon be porting this functionality to MacOS, Android and iOS.

All Sixscape products are fully IPv6 compliant, and will work in IPv4-only, dual stack and IPv6-only networks.