Read Part 1 first
When I started building a Python-based self-service certificate portal around OpenSSL, one question immediately came to mind:
If OpenSSL generates a server.crt, is that really a certificate issued by a Certificate Authority (CA)?
The answer is no—at least not in the way most enterprise environments use the term.
This distinction is fundamental to understanding how enterprise PKI works.
What OpenSSL Can Do
OpenSSL is an excellent cryptographic toolkit. It can:
- Generate private keys (RSA or ECC)
- Generate Certificate Signing Requests (CSRs)
- Create self-signed certificates
- Sign CSRs if you already possess a CA’s private key
For a self-signed certificate, the process is straightforward:
- Generate a private key.
- Generate a CSR.
- Use the same private key to sign the certificate.
In this case, the Subject and the Issuer are identical. The certificate is suitable for development and testing but is not inherently trusted by browsers or enterprise systems.
What a CSR Actually Is
A Certificate Signing Request (CSR) contains:
- The public key
- Common Name (CN)
- Subject Alternative Names (SANs)
- Organization information
- Other certificate metadata
Importantly, it does not contain the private key.
The private key never leaves the requester.
This is why generating a CSR is the standard first step in enterprise certificate provisioning.
Where Does a Trusted Certificate Come From?
After generating a CSR, the request must be sent to a trusted Certificate Authority.
That CA may be:
- DigiCert
- Entrust
- Sectigo
- Microsoft Active Directory Certificate Services
- HashiCorp Vault PKI
- AWS ACM Private CA
- Google Certificate Authority Service
- Another enterprise PKI platform
The CA validates the request and signs it using its own private key.
The resulting certificate now has:
- Subject: your application or server
- Issuer: the trusted Certificate Authority
That is what makes the certificate trusted.
Self-Signed vs. CA-Issued
A self-signed certificate is created with your own private key.
A CA-issued certificate is signed with the CA’s private key.
The difference seems small, but it changes everything.
Browsers, operating systems, and enterprise applications trust certificates because they trust the issuing CA—not because the certificate itself is cryptographically valid.
Building a Better Certificate Portal
Originally, my Streamlit application simply wrapped OpenSSL.
It could:
- Generate RSA and ECC keys
- Build CSRs
- Create self-signed certificates
- Download certificate bundles
While useful, I quickly realized that enterprise environments need much more.
Instead of thinking about an OpenSSL wrapper, the application should become a Certificate Management Portal.
The UI should support multiple provisioning options:
- Generate CSR only
- Generate a self-signed certificate
- Submit to an enterprise CA
- Submit to a public CA
The user experience stays the same, while the issuance backend changes.
A Pluggable Provider Architecture
Rather than tightly coupling the application to OpenSSL, a better design is to treat OpenSSL as just one provider.
The architecture becomes:
Certificate Portal
│
├── OpenSSL Provider
├── Microsoft CA Provider
├── HashiCorp Vault PKI Provider
├── DigiCert Provider
├── AWS ACM Private CA Provider
├── Azure Key Vault Provider
└── Google CA Service Provider
Each provider implements the same interface:
- Generate keys
- Submit certificate requests
- Retrieve issued certificates
- Renew certificates
- Revoke certificates
The UI never needs to know which provider is performing the work.
Enterprise Features
Once multiple providers are supported, the portal becomes much more than a CSR generator.
It can provide:
- Certificate templates
- Environment selection (Dev, Test, Production)
- Application ownership
- Approval workflows
- Certificate inventory
- Renewal notifications
- Revocation management
- Certificate expiration dashboards
- Audit logging
- Integration with enterprise HSMs
- Storage in HashiCorp Vault or Azure Key Vault
At this point, the project begins to resemble commercial Certificate Lifecycle Management (CLM) platforms.
Final Thoughts
OpenSSL is an outstanding foundation for certificate generation, but it is only one piece of the enterprise PKI ecosystem.
The real value lies in building a platform that abstracts the underlying certificate providers while delivering a simple, secure, and consistent user experience.
That evolution—from an OpenSSL wrapper to a full Certificate Management Portal—is what makes this project interesting. It combines Python development, cloud integration, PKI architecture, automation, and security engineering into a practical solution that could support everything from internal development certificates to enterprise-wide certificate lifecycle management across hybrid and multi-cloud environments.