PKI Certificate Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this standard:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this standard is to define how the Government of Malawi establishes, operates, and uses Public Key Infrastructure and digital certificates. It covers the lifecycle of certificates (issuance, validation, renewal, revocation), minimum key strengths and algorithms, use of Hardware Security Modules (HSMs) where required, and the roles and procedures needed to maintain secure communications and service availability. It is intended to be read alongside the Malawi Government Email Standards (for email TLS and certificate management) and the Government Server Security Hardening Standards (for TLS on servers).

1.2 Scope of Application

This standard applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors and consultants when they operate or use certificates for government systems or data. It covers certificates used for TLS/SSL (web, email, APIs), code signing, document or email signing (S/MIME, digital signatures), and client or device authentication where such use is under government control. It applies regardless of whether certificates are issued by a government-operated Certificate Authority (CA) or by a public or commercial CA under government policy.

1.3 Definitions and Key Terms

Certificate Authority (CA) – An entity that issues digital certificates by signing certificate requests with its private key. A Root CA is the top of a trust chain; Subordinate CAs may issue end-entity certificates under the Root. Government may operate its own CA or rely on approved external CAs.

Digital certificate – A binding between a public key and an identity (person, organisation, hostname, or device) signed by a CA. It is used to verify identity and to support encryption and digital signatures.

Key pair – Consists of a public key (shared) and a private key (kept secret). Key strength is measured in bits (e.g. 2048-bit RSA, 256-bit ECDSA). Strong keys and modern algorithms resist attack; weak or deprecated algorithms (e.g. MD5, SHA-1 for signing, RSA under 2048 bits) must not be used for new certificates.

Hardware Security Module (HSM) – A dedicated device or service that generates and stores private keys and performs cryptographic operations so that keys never leave the HSM. HSMs are required or recommended for root and issuing CA keys and for high-assurance use cases.

Revocation – The process of invalidating a certificate before its expiry (e.g. when a key is compromised or when a person leaves). Revocation is published via Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP).

TLS (Transport Layer Security) – The protocol used to encrypt data in transit (e.g. between a browser and a web server, or between mail servers). Certificates are used in TLS to authenticate the server and optionally the client.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Security – Certificates and keys must use approved algorithms and minimum key lengths (e.g. 2048-bit RSA or equivalent ECDSA as per NIST SP 800-57). Private keys must be protected (HSM or equivalent for CAs and high-assurance use). Weak or deprecated algorithms (RC4, DES, 3DES, MD5, SHA-1 for new signing) must not be used.

Availability – Services must not fail due to expired or missing certificates. Certificate renewal must be automated or scheduled so that expiry is avoided; monitoring and alerting must warn of impending expiry in time to act.

Legal validity – Use of digital signatures for official government communications must align with the Electronic Transactions and Cybersecurity Act (2016). Certificates used for signing must be issued by a CA that meets the Act’s requirements (or as interpreted by the responsible ministry).

Consistency – All government systems that use certificates (email, web, APIs, signing) must follow this standard so that policy is applied uniformly and so that the Malawi Government Email Standards and Government Server Security Hardening Standards are satisfied where they reference TLS and certificates.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor): Certificates and keys SHALL use approved algorithms and minimum key lengths (e.g. 2048-bit RSA or equivalent ECDSA per NIST SP 800-57). Private keys for CAs and high-assurance use SHALL be protected (HSM or equivalent). Certificate renewal SHALL be automated or scheduled so expiry is avoided; monitoring SHALL warn of impending expiry. Compromised or obsolete certificates SHALL be revoked within 24 hours. All exceptions SHALL be in the exception register with compensating controls and expiry.
• Prohibitions: MUST NOT use weak or deprecated algorithms (RC4, DES, 3DES, MD5, SHA-1 for new signing) or key lengths below minimum. MUST NOT grant exception without recording in exception register.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this standard. The National PKI Authority (or designated body under MoICT) is responsible for operating the government PKI (root and issuing CAs, CRL/OCSP, policy) and for defining Certificate Policies (CP) and Certification Practice Statements (CPS) where applicable.

PKI Authority – Operates the CA, issues and revokes certificates, and publishes CRLs/OCSP.

System Owner – Responsible for ensuring that their systems use certificates in line with this standard.

Security Officer – Validates compliance and governs exceptions.

System Administrator – Installs and renews certificates on systems and requests certificates from the CA.

3.2 Compliance Framework

Where certificate and key management are assessed against external baselines, the following order of precedence applies. The more restrictive requirement applies in case of conflict.

Malawian law. Electronic Transactions and Cybersecurity Act (2016) for digital signatures and cybersecurity; Data Protection Act (2024) where certificate or key management involves personal data.

NIST SP 800-57 (Recommendation for Key Management) for key strengths, algorithms, and lifecycle. NIST SP 800-52 Rev. 2 (Guidelines for the Selection, Configuration, and Use of TLS) for TLS configuration.

NIST SP 800-53 Rev. 5 (e.g. SC-8, SC-12, SC-13 for transmission confidentiality and key management) where government systems are categorised under that framework.

CIS Benchmarks and DoD STIGs for TLS and certificate configuration on specific platforms (e.g. web servers, mail servers), as referenced in the Government Server Security Hardening Standards.

Regional alignment. African Union and SADC frameworks where they address PKI or digital signatures; any Malawi-specific adoption or MACRA guidance.

3.3 System Categorisation

Certificate and key assurance levels may be tiered by system impact. High Impact systems (e.g. handling classified or highly sensitive data) require the strongest key protection (HSM where feasible), shortest certificate validity, and strictest revocation procedures. Medium and Low Impact systems still require minimum key strengths and TLS configuration as set in this standard and in the Email and Server Hardening standards.

3.4 Safe Exception Process

Exceptions to mandatory PKI or certificate requirements (e.g. legacy system unable to support TLS 1.2, temporary use of weaker key length during migration) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which an exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer.

• Request: The System Owner submits an exception request (government form or template), stating the requirement(s) from which an exception is sought, justification, and proposed compensating controls.
• Documentation: Each exception SHALL document: justification; compensating controls and timeline for remediation; risk acceptance by the System Owner and validation by the Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: Exceptions SHALL be reviewed at least quarterly; extensions require re-approval.
• Register: All exceptions SHALL be recorded in an exception register and made available for audit.

4. Certificate Lifecycle

4.1 Issuance

Certificates are issued only after validation of the requestor’s identity or control over the domain/hostname. For server certificates (TLS), the CA validates that the requestor controls the FQDN(s) in the certificate. For code signing, the requestor is validated as the authorised publisher. For individual signing certificates (e.g. S/MIME), identity is validated in line with the applicable Certificate Policy. Certificate requests are logged; issued certificates are recorded in a certificate inventory or database.

4.2 Validity and Key Length

Server and client certificates must use a minimum key length of 2048 bits for RSA (or equivalent strength for ECDSA, e.g. P-256). Root and subordinate CA certificates may use longer validity periods than end-entity certificates; end-entity certificate validity should not exceed 398 days for publicly trusted TLS certificates (per CA/Browser Forum baseline). Shorter validity (e.g. 90 days) reduces exposure if a key is compromised and supports automation. Algorithm and key strength must align with NIST SP 800-57 (e.g. no SHA-1 for new signatures; TLS cipher suites must use AEAD where possible, per NIST SP 800-52 and server hardening requirements).

4.3 Renewal

Renewal is performed before certificate expiry. Automated renewal (e.g. ACME protocol with Let’s Encrypt or an internal CA) is encouraged for server certificates to avoid human error. Where renewal is manual, a process and calendar must ensure renewal at least 30 days before expiry. Monitoring and alerting must notify responsible staff of certificates expiring within 30 days. Renewed certificates must meet the same key strength and algorithm requirements as new certificates.

4.4 Revocation

Certificates must be revoked when the private key is compromised or suspected compromised, when the identity or domain is no longer valid, or when required by policy (e.g. upon personnel separation). Revocation must be completed within 24 hours of the decision. Revocation is published via CRL and/or OCSP so that relying parties can check status. Revoked certificates must not be used; systems must be configured to check revocation where the application supports it.

4.5 Storage and Protection of Private Keys

Private keys for CAs must be generated and stored in an HSM or equivalent secure hardware. Private keys for servers and services must be stored with restricted file permissions and, where feasible, in a protected store or HSM. Private keys must never be shared or stored in plain text in code, configuration files, or version control. The Malawi Government Secrets Management Standards apply to storage of credentials and keys that are not in an HSM.

4.6 Certificate Profiles (Baseline)

To standardise issuance and reduce misconfiguration, the PKI Authority SHOULD define certificate profiles (templates) for common use cases. At minimum:

• TLS server certificate (web/API/email services)
• Client authentication certificate (where used)
• S/MIME signing/encryption certificate (where used)
• Code signing certificate (where used)

Profiles SHOULD define required key usages, SAN patterns, validity ranges, and renewal process, and be referenced in certificate requests.

5. Use Cases: TLS, Signing, and Code Signing

5.1 TLS for Services

All government-facing services (web, email, APIs) that transmit sensitive or personal data must use TLS 1.2 minimum; TLS 1.3 is preferred. Cipher suites must be restricted to strong, modern suites (e.g. AEAD); weak algorithms (RC4, DES, 3DES, MD5) must be disabled. This aligns with the Malawi Government Email Standards (TLS for email) and the Government Server Security Hardening Standards. Certificates must be valid, issued by a trusted CA, and cover the correct hostname(s). Mixed content (HTTP where HTTPS is expected) must be avoided.

5.2 Digital Signatures (Documents and Email)

Where the government uses digital signatures for official documents or email (S/MIME), certificates must be issued by a CA that meets the requirements of the Electronic Transactions and Cybersecurity Act (2016) for legal validity. Signing keys must be protected (e.g. in a smart card or HSM for high-assurance use). The Malawi Government Email Standards reference S/MIME and digital signatures; implementation must comply with both documents.

5.3 Code and Artifact Signing

Where government distributes software or signed artifacts (e.g. scripts, packages), code signing certificates must be used to attest to the origin and integrity of the code. Private keys for code signing must be protected (e.g. HSM or dedicated secure build environment). Expired or revoked signing certificates must not be used.

5.4 BIMI and Email Brand Certificates

The Malawi Government Email Standards reference BIMI (Brand Indicators for Message Identification), which may require Verified Mark Certificates (VMCs). Where BIMI is adopted, VMCs must be obtained from an accredited provider and managed in line with this standard (renewal, revocation).

6. Operational Requirements

6.1 Certificate Inventory and Monitoring

Government entities must maintain an inventory of certificates they use (server, signing, client), including issuer, subject, validity dates, and system or service. Inventory must be updated when certificates are issued, renewed, or revoked. Monitoring must alert on certificates expiring within 30 days (or as configured) so that renewal or replacement can be completed in time.

6.2 Incident and Compromise Response

If a private key is compromised or suspected compromised, the corresponding certificate must be revoked immediately and the incident reported in line with the government’s incident response procedures. Affected systems must be re-keyed and new certificates issued. Root or subordinate CA compromise requires a coordinated response per the PKI Authority’s incident plan and may require re-issuance of the CA and all dependent certificates.

6.3 Backup and Recovery

CA private keys and critical PKI configuration must be backed up securely. Recovery procedures must be documented and tested so that PKI operations can be restored after a disaster. Backup and recovery must not expose private keys to unauthorised parties.

7. Legal Compliance and Governance

7.1 Electronic Transactions and Cybersecurity Act (2016)

The Act provides the legal framework for electronic communications and digital signatures. Certificates used for digital signatures that are to have legal effect must be issued and managed in accordance with the Act and any regulations or guidelines issued thereunder. This standard is intended to support such compliance by defining strong key management, lifecycle, and operational controls.

7.2 Data Protection Act (2024)

Where certificate or PKI operations process personal data (e.g. identity data used to issue signing certificates), processing must comply with the Data Protection Act: lawful basis, minimisation, security, and breach notification to MACRA where applicable.

7.3 Audit and Accountability

PKI operations must be auditable. Logs of certificate issuance, renewal, and revocation must be retained in line with government records retention. Access to CA systems and key ceremonies must be logged. Auditors must be able to verify that the lifecycle and key strength requirements of this standard are met.

8. Training and Awareness Program

8.1 PKI Operators and System Administrators

Personnel who operate the CA, issue certificates, or install and renew certificates on systems must be trained on this standard, on key and certificate lifecycle, and on secure key storage and revocation procedures. Training must be refreshed when policy or technology changes.

8.2 System Owners and Security Officers

Personnel responsible for systems that use certificates must understand their obligations (inventory, renewal, revocation on compromise) and how to request support from the PKI Authority. Awareness of TLS and certificate-related security (e.g. no mixed content, check revocation) is part of general security training.

9. Verification and Evidence Baseline (Audit-Ready PKI)

To make this standard auditable, ministries and the PKI Authority SHOULD maintain evidence that demonstrates: certificate inventory; key strength and algorithm compliance; lifecycle (issuance, renewal, revocation); HSM/key protection where required; exception register; annual PKI policy review. What internal audit checks: Sample of certificates for key strength and lifecycle; CA logs and revocation; exception register. Sampling: Quarterly sample of certificates; annual policy review. Escalation: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

9.1 Compliance Reporting

10. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.10, A.9, A.12
• NIST SP 800-53 Rev. 5 – controls SC-12, SC-13, IA-5
• Benchmarks – none specific

Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.

11. Appendices

Appendix A: Minimum Key Strengths and Algorithms (Summary)

• Use
• Minimum key length (RSA)
• Equivalent ECDSA
• Deprecated
• TLS server/client
• 2048 bits
• P-256
• SHA-1 for signing; RC4, DES, 3DES
• Code signing
• 2048 bits
• P-256
• SHA-1
• CA (subordinate)
• 2048 bits
• P-256
• SHA-1 for new issuance
• CA (root)
• 4096 bits recommended
• P-384
• SHA-1 for new issuance
• (Align with NIST SP 800-57 for current recommendations; algorithm deprecation may change over time.)

Appendix B: Related Standards

Malawi Government Email Standards (TLS, S/MIME, BIMI, certificate management). Government Server Security Hardening Standards (TLS for administrative access, encryption in transit). Malawi Government Secrets Management Standards (storage of keys and credentials not in HSM). Malawi Government IAM Standards (certificate-based authentication where used).

Appendix C: Control and Legal Mapping

• Appendix D: Evidence and Artifact Checklist
• Certificate inventory: List of certificates (or link to inventory) with issuer, subject, validity, and owner; updated on issuance and revocation.
• Key strength and algorithm: Evidence that new certificates meet minimum key length and algorithm requirements (e.g. 2048-bit RSA or P-256 ECDSA); deprecated algorithms not in use.
• Lifecycle: Issuance and revocation records; evidence of renewal at least 30 days before expiry where process allows; CRL/OCSP availability where used.
• HSM and key protection: Where HSM is required, evidence of HSM use for CA or high-assurance keys; private keys not in plain text in code or config.
• Exceptions and audit: Exception register with requirement, justification, compensating controls, and review/expiry dates; annual PKI policy review.
• Appendix E: Templates (Minimum)

E.1 Certificate Request Record (Template)

• Requestor and system owner
• Certificate profile (TLS/S/MIME/code signing/etc.)
• Subject and SANs requested
• Validation method performed
• Validity period and renewal target
• Issuance decision and approver

E.2 Key Ceremony Checklist (Template)

• Ceremony purpose (root/subordinate issuance, key rotation)
• Participants and roles
• Environment controls (offline, access control)
• Steps executed and timestamps
• Evidence retained (logs, approvals)

E.3 Certificate Inventory Schema (Minimum Fields)

• Certificate identifier, issuer, subject, SANs
• Validity dates, renewal target date
• System/service owner
• Profile name
• Revocation status and reason (if revoked)

References

Electronic Transactions and Cybersecurity Act (2016) (Malawi).

Data Protection Act No. 3 of 2024 (Malawi).

Malawi Government Email Standards (MoICT, E-Government Division).

Government Server Security Hardening Standards.

NIST SP 800-57, Recommendation for Key Management.

NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of TLS.

NIST SP 800-53 Rev. 5 (SC-8, SC-12, SC-13).

CIS Benchmarks / DoD STIGs (TLS and certificate configuration).

CA/Browser Forum Baseline Requirements (for publicly trusted TLS certificates where applicable).