Most organizations still request SSL/TLS certificates through email, ticketing systems, or manual command-line operations. Developers often have to remember lengthy OpenSSL commands, security teams must validate requests, and operations teams spend time provisioning certificates into web servers, cloud platforms, or key vaults.
It doesn’t have to be this way.
As a learning project, I’m building a Python-based self-service certificate portal that provides a simple web interface on top of OpenSSL while laying the foundation for enterprise certificate lifecycle management.
Why Build a Wrapper Around OpenSSL?
OpenSSL is one of the most powerful cryptographic toolkits available. It can generate keys, create Certificate Signing Requests (CSRs), issue certificates, inspect certificate chains, and perform cryptographic operations used across the industry.
The challenge is usability.
Generating a certificate request often involves long command lines with numerous parameters, making it easy to introduce mistakes such as:
- Incorrect Subject Alternative Names (SANs)
- Weak key sizes
- Invalid certificate subjects
- Missing certificate extensions
- Inconsistent naming conventions
A web-based interface can validate these inputs before OpenSSL is ever invoked.
The Technology Stack
The project uses:
- Python for the application logic
- Streamlit for the web interface
- OpenSSL for cryptographic operations
- HashiCorp Vault PKI (planned) for enterprise certificate issuance
- Azure Key Vault (planned) for secure certificate storage and lifecycle management
This architecture separates the user experience from the underlying cryptographic engine while making it easy to add additional certificate providers in the future.
Understanding the Certificate Request Form
The portal collects the information required to generate a standards-compliant Certificate Signing Request.
Common Name (CN)
Traditionally, the Common Name represented the primary hostname of the server.
Example:
app.company.com
Although modern browsers primarily validate Subject Alternative Names, the Common Name remains an important part of the certificate subject.
Organization
Identifies the owning organization.
Acme Corporation
Useful for inventory, governance, and auditing.
Organizational Unit
Represents the team requesting the certificate.
Examples include:
- Platform Engineering
- Security
- Networking
- DevOps
Country, State, and Locality
These fields describe the organization’s geographic location and become part of the X.509 certificate subject.
C=US
ST=Texas
L=Austin
Subject Alternative Names (SAN)
This is the most important field in modern TLS certificates.
A single certificate can protect multiple hostnames:
DNS:app.company.com
DNS:api.company.com
DNS:payments.company.com
or IP addresses:
IP:10.1.20.5
During a TLS handshake, clients validate the hostname against the SAN extension rather than the Common Name.
Key Type
The portal supports both:
- RSA
- Elliptic Curve (EC)
RSA remains universally compatible, while EC certificates provide smaller keys, faster handshakes, and lower CPU utilization.
Key Size
For RSA:
- 2048-bit
- 3072-bit
- 4096-bit
Larger keys provide additional security but increase computational cost.
EC Curve
Supported curves include:
- prime256v1 (P-256)
- secp384r1 (P-384)
These are among the most widely deployed curves in enterprise environments.
Certificate Validity
Defines how long the certificate remains valid.
Typical enterprise lifetimes range from several months to one year, depending on organizational policy and automation capabilities.
Request Type
The portal supports two workflows:
CSR Only
Generate a private key and Certificate Signing Request for submission to an external Certificate Authority.
Self-Signed
Generate a private key, CSR, and a self-signed certificate for development and testing environments.
Private Key Encryption
Users can encrypt their private key with AES-256 using a passphrase, ensuring that the key cannot be used without the correct password.
Security Considerations
A certificate portal should never simply expose OpenSSL through a web interface.
Instead, it should:
- Validate every input field
- Restrict supported algorithms
- Prevent arbitrary command execution
- Generate certificates in temporary workspaces
- Protect private keys throughout their lifecycle
- Maintain complete audit logs
Security should be designed into the portal from the beginning rather than added later.
The Next Evolution: Enterprise PKI
The current implementation focuses on OpenSSL, but the long-term vision is much broader.
Future capabilities include:
- Single Sign-On (SSO)
- Role-Based Access Control (RBAC)
- Certificate templates
- Approval workflows
- Certificate inventory
- Automatic renewals
- Expiration notifications
- Revocation management
- Audit reporting
- Integration with HashiCorp Vault PKI
- Azure Key Vault provisioning
- Microsoft Active Directory Certificate Services
- DigiCert and other commercial Certificate Authorities
At that point, the project evolves from an OpenSSL wrapper into a complete certificate lifecycle management platform.
Why This Matters
As organizations adopt cloud-native architectures, Kubernetes, service meshes, APIs, microservices, and mutual TLS, the number of certificates grows exponentially. Managing thousands of certificates manually is no longer practical.
Automating certificate requests, approvals, issuance, storage, renewal, and auditing reduces operational effort while improving security and compliance.
This project is intended to demonstrate how a relatively small Python application can evolve into an enterprise-grade PKI automation platform that simplifies certificate management without sacrificing security.
I’m looking forward to sharing the implementation as it evolves—from a simple OpenSSL wrapper into a fully featured certificate lifecycle management solution.
Also read:
Building an Enterprise Certificate Self-Service Portal with Python, Streamlit, and OpenSSL – Part 2