ZoTrus provides HTTPS automation solutions that help organizations automate SSL/TLS certificate lifecycle management and deploy secure HTTPS connections across different infrastructure environments. The solution supports three deployment approaches: ACME Client, HTTPS Automation Gateway, and ACME Cloud Service. Each approach addresses different infrastructure and operational requirements. The HTTPS Automation Gateway is ZoTrus’s enterprise-focused approach for environments where modifying existing Web servers or business applications is difficult or undesirable.
ZoTrus offers three deployment approaches.
These are different deployment architectures, not product tiers. The appropriate approach depends on server access, infrastructure constraints, and CDN API availability.
ACME clients are already widely adopted and provide an effective solution for organizations that can install software and manage certificate deployment on their Web servers. Many CDN providers also offer built-in certificate automation. ZoTrus’s enterprise focus is therefore on a different challenge: organizations may operate legacy platforms, packaged applications, dedicated appliances, or mission-critical systems that are difficult or undesirable to modify. The HTTPS Automation Gateway moves public-facing HTTPS termination, certificate lifecycle management automation, and supported cryptographic capabilities to a dedicated gateway, helping enterprises modernize website security while keeping existing systems largely unchanged.
An ACME client is suitable when you have administrative control over Web servers and can install client software and configure automated certificate deployment. An HTTPS Automation Gateway is more suitable when origin servers run legacy platforms, packaged applications, dedicated appliances, or mission-critical systems that should not be modified, or when you want to centralize public-facing HTTPS termination and supported cryptographic capabilities. An ACME Cloud Service is suitable when you use a CDN with a supported API integration and want certificate automation to be managed through that CDN. The choice depends on deployment requirements, not different levels of ACME functionality.
Start with your existing infrastructure. If you can install and manage software on your Web servers, an ACME client may be appropriate. If you already use a CDN with a compatible API and its certificate automation meets your requirements, CDN-based automation may be appropriate. If your origin systems are difficult to modify, or you need centralized HTTPS termination, certificate automation, and supported cryptographic capabilities at the network edge, consider the HTTPS Automation Gateway. The final design should also account for traffic volume, certificate profiles, algorithms, WAF requirements, availability, and existing network security devices.
For supported certificate types and integrations, ZoTrus automates certificate lifecycle operations such as certificate application, domain validation, issuance, retrieval, deployment, and renewal. The exact operations depend on the selected deployment approach, certificate profile, validation requirements, CA integration, and configuration.
The five-year period refers to the certificate service term included with the applicable HTTPS Automation Gateway offering. During that term, the included service supports automated issuance and renewal of specified dual-algorithm SSL certificates like ECC DV +SM2 OV according to the purchased package. It does not mean an individual SSL/TLS certificate is valid for five years. Individual validity periods follow applicable CA requirements and certificate profiles. Domain coverage, certificate profiles, and entitlements are determined by the selected package. This advantage is customers do not need to buy SSL certificate from CA; it is included and integrated in the Gateway order.
The gateway’s default certificate configuration combines an internationally trusted ECC Domain Validation (DV) SSL certificate with an SM2 Organization Validation (OV) SSL certificate. This dual-algorithm combination serves different purposes. The SM2 OV certificate can be particularly useful for organizations in Hong Kong and Macao that connect to systems in mainland China or provide services to users there, where support for China’s commercial cryptography can help address relevant compliance and interoperability requirements. Whether a specific legal or regulatory requirement applies depends on the organization’s activities and the systems involved.
For customers in other markets, SM2 support adds another cryptographic option and contributes to algorithm diversity. The SM2MLKEM768 hybrid key-exchange option can also provide an additional supported path for post-quantum transition. No cryptographic algorithm or post-quantum scheme should be treated as permanently or conclusively secure; continued cryptanalysis, evaluation, and implementation review remain essential. Algorithm diversity can reduce reliance on a single cryptographic approach, but it does not by itself guarantee security.
Yes. The gateway can support automated deployment of OV certificates, including RSA or ECC certificates, subject to the selected certificate profile and the availability of the required CA integration. It can also be configured to use certificates issued by a customer-specified CA when the relevant issuance, validation, and deployment workflow is supported.
These customized OV configurations may substantially increase the overall gateway and certificate-service cost, depending on the CA, certificate profile, validation process, and integration requirements. DV and OV certificates provide the same cryptographic strength when they use the same key algorithm and key size. The difference is the level of identity validation: OV certificates include organization identity vetting, while DV certificates validate control of the domain.
This is why the default configuration uses an ECC DV certificate together with an SM2 OV certificate issued by ZoTrus CA. This combination provides international algorithm compatibility and an organization-validated SM2 certificate while keeping the service more cost-effective. ZoTrus automated issuance workflow for its SM2 OV certificate also helps reduce operational complexity and total cost of ownership.
The gateway uses ECC for its default international SSL certificate because elliptic-curve cryptography can provide comparable security strength with significantly smaller keys. For example, a 256-bit elliptic-curve key is commonly regarded as providing security strength roughly comparable to a 3072-bit RSA key.
Smaller keys and signatures can reduce handshake data and bandwidth use, while ECC operations are generally efficient in modern TLS implementations. These characteristics can help reduce processing overhead and energy consumption in infrastructure and client devices, including mobile devices. RSA remains widely supported and can be selected where compatibility or a specific deployment requirement calls for it.
ZoTrus integrates with multiple supported certificate authorities and issuance channels. When configured conditions prevent a selected CA from issuing a certificate, the service can select or switch to another supported CA channel, subject to certificate-profile compatibility, domain-validation requirements, and the operating status of available integrations. This reduces dependence on a single CA and provides more flexibility. Switching behavior depends on certificate type and issuance policies.
Relying on a single CA can create operational dependency. If that CA experiences an issuance problem or a change affecting the required certificate profile, an organization may have limited alternatives. Multi-CA integration provides additional issuance channels and greater flexibility. It can improve certificate-supply resilience, but does not guarantee transparent switching in every outage or for every certificate type. Validation requirements, CA policies, and integration availability still apply, but the bottom line is a DV SSL certificate auto-switch issuance guaranteed to keep HTTPS work uninterrupted.
ZoTrus integrates with multiple supported international and domestic certificate authorities for certificate issuance. The available CA channels depend on certificate type, validation method, profile, and service configuration. CA integrations may change over time; contact ZoTrus for the current CA list and the requirements for your intended deployment.
The ZoTrus HTTPS Automation Gateway is a dedicated hardware appliance deployed between the Internet and an organization’s existing Web servers and business systems. It automates supported SSL/TLS certificate lifecycle operations and handles public-facing HTTPS connections, including TLS termination and traffic forwarding. Depending on the model and configuration, it can also provide supported multi-cryptographic algorithms, multi-CA certificate management, HTTPS offloading, and WAF protection.
No. When using the ZoTrus HTTPS Automation Gateway, you do not need to install an ACME client on each origin server and no need to install SSL certificate on servers. The gateway performs supported certificate lifecycle operations and handles public-facing HTTPS connections. This is useful for servers that cannot run ACME client software or where changes to the existing environment are restricted.
The gateway is designed to minimize changes to existing origin servers and business applications. It is deployed in front of the existing Web infrastructure, handles public-facing HTTPS connections, and forwards permitted traffic to origin systems. Exact network, forwarding, and origin-side configuration depends on the existing architecture and security policy. It avoids requiring application changes solely to enable the gateway’s supported public-facing TLS capabilities.
The gateway is placed between Internet clients and existing Web servers or business systems. It receives public HTTPS connections, performs TLS termination using certificates and algorithms configured on the gateway, applies configured security policies, and forwards permitted requests to the appropriate origin systems. Its certificate automation functions manage supported operations such as application, validation, issued certificate retrieve, deployment, and renewal. The precise topology depends on the organization’s network design.
Traditional HTTPS gateways commonly focus on TLS termination, traffic forwarding, and related network functions. The ZoTrus gateway combines these functions with automated SSL/TLS certificate lifecycle management and multiple CA integrations. It also supports traditional and hybrid post-quantum cryptographic algorithms, HTTPS offloading, and WAF protection. Its purpose is not only to process HTTPS traffic, but also to automate certificate operations and help enterprises introduce supported cryptographic capabilities without upgrading every origin server.
No. The gateway is designed to work with existing Web servers, business applications, and network infrastructure. It handles assigned public-facing HTTPS functions and forwards permitted traffic to existing origin systems. It can also be deployed alongside an existing CDN, depending on network architecture. It does not automatically replace a CDN’s content distribution functions; its role and placement should be determined as part of the overall network design.
The supported algorithms and certificate types depend on the selected solution, gateway model, software version, and configuration. The gateway supports traditional public-key algorithms such as RSA, ECC and SM2. In supported gateway configurations, hybrid post-quantum key exchange algorithms X25519MLKEM768 and SM2MLKEM768 are also supported. Actual availability and negotiation depend on model, firmware, TLS settings, client capabilities, and certificate profile. Confirm exact compatibility with ZoTrus for a specific deployment.
Hybrid post-quantum cryptography combines a conventional key-establishment mechanism with a post-quantum mechanism. In the supported TLS hybrid key exchange schemes, this combines an established elliptic-curve mechanism with ML-KEM-768, a post-quantum key-encapsulation mechanism. Hybrid key exchange provides a transition path incorporating post-quantum key establishment while retaining a conventional cryptographic component. It is distinct from a post-quantum digital-signature algorithm or a post-quantum certificate.
Yes, the gateway supports X25519MLKEM768 and SM2MLKEM768. X25519MLKEM768 combines X25519 with ML-KEM-768, while SM2MLKEM768 combines an SM2 algorithm elliptic-curve mechanism with ML-KEM-768. Available choices and negotiation depend on model, software version, TLS configuration, and client capabilities. These hybrid key exchange options do not mean X25519 and SM2 certificates themselves are post-quantum signature certificates.
The gateway can provide a migration path for supported two hybrid post-quantum HTTPS key exchange algorithm by handling public-facing TLS connections. This can reduce the need to upgrade every origin server or business application solely to support the gateway’s enabled hybrid key exchange algorithms. Actual protection depends on client support, TLS negotiation, configuration, and network architecture. Other cryptographic uses and internal connections should be assessed separately as part of a broader migration plan.
Not necessarily. When the gateway terminates the public-facing HTTPS connection, clients negotiate TLS with the gateway rather than directly with the origin server. The gateway can provide its supported two hybrid post-quantum key exchange capabilities on that connection without requiring the origin application itself to implement those algorithms. This does not make every part of the end-to-end environment post-quantum secure; origin-side connections, internal protocols, stored data, and other cryptographic operations must be assessed separately.
No. Supporting hybrid post-quantum algorithms does not mean every HTTPS connection automatically uses them. Negotiation depends on client browser or software support, TLS protocol version, gateway configuration, and enabled algorithms. A connection can use a hybrid post-quantum key exchange only when the client and gateway support a compatible algorithm and the configuration permits it.
The gateway provides integrated WAF capabilities in supported configurations. When it terminates HTTPS, it can inspect decrypted HTTP traffic and apply configured security policies before forwarding permitted requests to origin servers. Available rules, protection functions, performance, and configuration options depend on model and software. WAF complements an organization’s broader security architecture; it does not replace every other security control.
Yes. The gateway is designed to work alongside existing network and security infrastructure, including firewalls, intrusion prevention systems (IPS), WAF appliances, anti-DDoS systems, and load balancers. Placement and traffic flow should follow the organization’s network topology and security policies. Existing devices can continue their respective functions while the gateway handles assigned HTTPS and certificate automation capabilities.
The gateway handles public-facing HTTPS encryption and decryption. It can therefore reduce TLS processing workload on origin servers and centralize supported certificate and cryptographic operations. The actual performance benefit depends on traffic volume, gateway model, enabled security functions, network topology, and whether the origin-side connection is also encrypted.
For certificates managed and used by the gateway, the corresponding private keys are generated and protected within the gateway hardware according to its supported key-management design. This allows the gateway to perform public-facing TLS operations without requiring associated private keys to be managed manually on each origin server, this greatly reduces the private key exposure. Key generation, storage, backup, access control, and hardware protection details depend on model and documented security configuration.
ZoTrus offers multiple gateway models for different hardware platforms, traffic levels, and deployment scales, including MG-1, MG-8, MG-9, MG-10, MG-11, and MG-13. Selection should consider the number of websites, expected connections and traffic, required algorithms, enabled security functions, high-availability requirements, and hardware or deployment preferences. Published site capacity is a sizing reference, not a substitute for workload-specific performance assessment. ZoTrus can help evaluate requirements and recommend a suitable model.
The solutions address organizations seeking automated SSL/TLS certificate management and secure HTTPS deployment. ACME clients can suit teams that manage their own Web servers; CDN API integration can suit users of compatible CDN services; and the HTTPS Automation Gateway is particularly relevant to organizations operating complex, legacy, or mission-critical Web infrastructure that they do not want to modify extensively. Typical gateway environments include critical business infrastructure, banking and financial services, government and public services, large enterprises, healthcare, and education.
Assess whether origin servers can run ACME clients and whether they can be modified safely. Consider whether your CDN offers a compatible API and whether its native certificate automation meets your needs. Also review certificate types and validation requirements, number of websites, traffic volume, required algorithms, PQC migration objectives, WAF requirements, existing security devices, and high-availability needs. If the environment is difficult to modify or you want to centralize public-facing HTTPS and certificate operations, a gateway-based architecture may be appropriate. ZoTrus can review deployment requirements and help determine a suitable solution.