Chat With Us
We are here for you!
Talk to a fellow human.
Leveraging a public root delivers instant universal trust across your user base. An organization may also have servers that are not external-facing and don't need publicly rooted certificates. These servers, however, may still need authentication, signing, and capability, to establish a secure TLS session with other internal servers or applications. This post explains three deployment architectures to consider for using Sectigo Private PKI.
If you have a website that provides a service to clients outside of your organization, chances are, it has a digital certificate that is publicly rooted. This means the chain of trust leads to a root certificate issued by a well-known Certificate Authority (CA) already trusted by your users’ browsers and other major application technologies (e.g., Java). Leveraging a public root enables you to instantly achieve universal trust across your user base.
You may also have a number of other servers that are not external facing and will not need publicly rooted certificates. These servers, however, may still need authentication and signing capability to establish a secure TLS session with other internal servers or applications. The root of trust for these servers would be a privateCertificate Authority (CA); a CA of your own, which is part of the cloud-based Sectigo Private PKI offering.
With our Private PKI solution, you can brand the certificates for your servers, devices, and users. Since the purpose of this CA is to serve your organization only, it will provide a tighter control when this PKI infrastructure is used for internal user authentication. For this reason, Private PKI is immensely popular for deployment in the enterprise IT as well as cloud-native DevOps and Internet of Things (IoT) environments.
Three Deployment Scenarios
You have three deployment architectures to consider for using Sectigo Private PKI:
Many of our customers prefer Option 1 above as all PKI operational aspects, including hosting, maintenance, security, and compliance, are taken care of by Sectigo. You simply obtain and install certificates from us and deploy them into your environment. Some customers, however, may already have a Private Root CA, or their enterprise security policy may dictate that the Root CA reside in their environment. In this case, Sectigo may host and manage the Issuing CAs, which will be signed by their on-premise Root CA.
Since the bulk of the work is done at the Issuing CA, it offloads them from a lot of day-to-day overhead. In the third situation above, you may have a CA, such as, Microsoft CA, HashiCorp Vault PKI instance, or Kubernetes CA, running in your environment and integrated with your applications. You can greatly improve your security posture by having Sectigo host an offline Root CA with keys stored in a Hardware Security Module (HSM) in an industry-standard compliant, audited data center, and sign your existing CA, which will then issue and manage the end entity certificates to users and devices.
We can guide you in deciding which option is most suitable in your situation and assist in implementing the chosen deployment architecture. Figures 1, 2 and 3 depict all three scenarios.
IT and DevOps Friendly Private PKI
For container-to-container and application-to-application authentication and secure communication between them, you will likely leverage privately trusted certificates in your AWS, Azure, or other cloud environment. Sectigo Private PKI is being integrated with the most popular DevOps tools so that when you are rolling out your infrastructure and applications in an automated fashion, you can seamlessly enroll certificates from Sectigo Private PKI and manage their lifecycle. In addition, to ensure that your software is not tampered with, you would want to code sign your container and other applications, which could be issued from the same PKI infrastructure as well.
With the advent of the cloud friendly micro-service architecture, your services may come and go which will require high volume, short-lived certificates. Sectigo Private PKI will be capable of issuing and managing certificates with a short life cycle and our licensing scheme will support this business model to make it cost efficient for you.
Automation plays a key role in our architecture. Sectigo Private PKI helps you with the end-to-end automation of issuance and installation of certificates.
We support industry standard protocols, for instance, Enrolment over Secure Transport (EST), Simple Certificate Enrolment Protocol (SCEP), and are working on integrations with third-party tools, e.g., Kubernetes cert-manager, HashiCorp Terraform and Vault, Ansible, Puppet, Chef, and others. In Microsoft Windows environments, you can leverage our auto-enrollment capability to issue certificates from Sectigo Private PKI. For non-Microsoft entities, you can use other supported tools tested with our Private PKI in order to manage certificates for them.
This recent blog, “When it Comes to SSL Certificate Automation, Sectigo Provides Plenty of Options,”provides useful information about the suite of automation tools that Sectigo employs to reduce administrators’ manual labor.
Central Management Console
Our customers rarely prefer to go to two different vendors to obtain their public and private certificates. With that in mind, we designed our system so that you can manage everything from a central console known as Sectigo Certificate Manager. The administrator’s experience is the same, regardless of the type of certificates you manage. All your certificates are visible in the central console with their status and expiry dates. Certificate Manager can discover all your certificates, even if they are not from Sectigo, and report on them.
We have more exciting plans to provide you an all-encompassing single pane of glass view of your Private PKI, public SSL and enterprise IoT certificates. Contact us for more information.