INTERNSHIP REPORT

OF
5th Year
CyberSecurity

By

Othmane Chakouk

Implementation of Tier-2 PKI with AD CS and Linux

Integration : Threat Simulation and Monitoring via SIEM

Tuteur académique : Tuteur

professionnel :
M.Khalid Chougdali M. Errouifi
Mohamed Amine

1
 2024 -2025

Implementation of Tier-2 PKI with AD CS and Linux Integration : Threat Simulation

and Monitoring via SIEM

Résumé :

Ce rapport présente un projet réalisé dans le cadre d’un stage de fin d’études en cybersécurité
chez DXC Technology Maroc. L’objectif principal était la mise en place d’une infrastructure
PKI de niveau 2, déployée dans un environnement hybride combinant Linux et Windows. Le
projet a couvert l’implémentation d’Active Directory Certificate Services (AD CS),
l’installation d’un serveur OCSP sous Linux avec Apache2, ainsi que la configuration
d’OCSP Stapling pour optimiser la vérification des certificats. Des simulations d’attaques
ciblées ont été menées afin d’évaluer la robustesse de l’infrastructure : attaques OCSP Relay
et DoS sur la partie Linux, et élévations de privilèges ESC1 et ESC7 sur l’infrastructure AD
CS via l’exploitation de modèles de certificats mal configurés. L’ensemble a été intégré à une
solution SIEM basée sur la stack ELK (Elasticsearch, Kibana), avec Winlogbeat pour la
collecte des journaux. Des règles personnalisées et des tableaux de bord ont été développés
pour détecter en temps réel les abus liés aux certificats. Ce projet met en lumière les enjeux
de sécurité des environnements PKI hybrides et démontre l’efficacité de la supervision SIEM
dans la détection d’attaques avancées sur les services de certificats.

Mots clés: PKI, OCSP, OCSP Stapling, Apache2, TLS Hardening, SIEM ELK,
Cybersecurity, DXC Technology Morocco, Replay Attack, Man-in-the-Middle, ESC1, AD
CS, ESC7, Log Analysis, RFC

2|Page
 Implementation of Tier-2 PKI with AD CS and Linux Integration: Threat Simulation
and Monitoring via SIEM

Abstract:

This report outlines a final-year cybersecurity internship project at DXC Technology

Morocco, focused on implementing a secure Tier-2 PKI infrastructure across both Linux and
Windows environments. The project involved setting up AD CS on Windows, deploying an
OCSP responder with Apache2 on Linux, and enabling OCSP Stapling to improve certificate
validation. To assess system resilience, several attack scenarios were simulated. These
included OCSP Relay and DoS attacks in the Linux-based PKI, and ESC1/ESC7 privilege
escalation attacks exploiting misconfigured certificate templates in AD CS. The infrastructure
was integrated with a SIEM solution using the ELK Stack (Elasticsearch, Kibana), with
Winlogbeat forwarding logs for real-time detection and correlation. Custom rules and
dashboards were created to monitor certificate abuse, enhancing visibility and response to
PKI-related threats. This project highlights the practical challenges of securing hybrid PKI
systems and demonstrates effective detection of advanced certificate-based attacks.

KeyWords: PKI, OCSP, OCSP Stapling, Apache2, TLS Hardening, SIEM ELK,
Cybersecurity, DXC Technology Morocco, Replay Attack, Man-in-the-Middle, ESC1, AD
CS, ESC7, Log Analysis, RFC.

3|Page
 Contents

Introduction :............................................................................................................... 6
I. Part1 : Organizational Background.......................................................................7
1. DXC Technology Morocco :..................................................................................7
2. Key figures and activities :.................................................................................8
3. Expertise and Commitment to Cybersecurity :...................................................9
4. Security Approach and Evolution at DXC Technology.....................................10
II. Part2 : PROJECT CONTEXT AND REQUIREMENTS STUDY..........................11
1. Background of the Internship and Project Objectives...................................11
2. Problematic : Securing Public Key Infrastructure (PKI) Against Advanced
Threats................................................................................................................... 12
4. Requirements Study and Best Practices :....................................................14
3.1 Commercial PKI Management and Monitoring Solutions :...........................14
4.2 Open-source Tools and Frameworks :............................................................14
Part1 : Public Key Infrastructure (PKI) Fundamentals :.............................................17
Part2 : Security Standards and Best Practices.......................................................23
1.2. RFC 6960 (OCSP Protocol).............................................................................24
III. Project Phases.................................................................................................32
a. Phase 1 : Configuring Pfsense..................................................................32
b. Phase 2 : Intregrating and Configuration of Splunk...................................32
c. Phase 3 : Simulating Brute force Attacks..................................................32
d. Phase 4 : Verification and Analysis...........................................................32
Conclusion................................................................................................................. 33

4|Page
 ACKNOWLEDGEMENT :

Upon the completion of this project, I would like to extend my heartfelt gratitude to everyone
who contributed to its success, both directly and indirectly.

I am deeply thankful to the general management of BARID AL-MAGHRIB, the human

resources department, and the information systems department for providing me with the
opportunity to undertake my internship within their esteemed organization.

I would also like to express my sincere appreciation to all those who showed exceptional
collaboration and initiative, especially my supervisors at BARID AL-MAGHRIB and my
mentors at the university, for their invaluable advice, suggestions, and recommendations.

5|Page
 Introduction :
During the final year of my cybersecurity studies, I had the opportunity to complete a
professional internship at DXC Technology Morocco, which took place from February 3
to June30, 2025. The main objective of this internship was to design and deploy a secure
Public Key Infrastructure (PKI), while applying best practices and aligning with
international standards like ISO 27001 and NIST.
The project involved creating two different PKI environments : a two-tier PKI setup on
Linux systems, and another using Microsoft Active Directory Certificate Services (AD
CS). This gave me hands-on experience with both open-source and enterprise-level
technologies, and a deeper understanding of how PKI can be adapted to different
infrastructures.
One of the key components I worked on was deploying an OCSP (Online Certificate
Status Protocol) server with OCSP Stapling to ensure fast, reliable certificate validation. I
also focused on hardening the systems, improving cryptographic configurations, and
making sure each environment was resistant to common threats.
To enhance visibility and support real-time threat detection, I integrated a SIEM solution
based on the ELK stack (Elasticsearch, Logstash, Kibana). This setup allowed me to
collect and correlate logs from across the PKI environments and monitor for unusual
activity.
As part of the validation phase, I carried out several controlled attack simulations to assess
how secure and resilient the infrastructure truly was. In the Linux-based PKI, I tested the
system’s response to an OCSP Replay Attack, examining how well the environment
could detect and respond to tampered certificate status messages. For the Windows-based
PKI, I simulated ESC1, ESC7 attacks targeting weaknesses in certificate template
permissions to AD CS to test the effectiveness of my security configurations and logging.
This internship was not just a technical challenge but also a rewarding learning
experience.
It allowed me to apply what I’ve learned in a real-world setting, sharpen my skills in
infrastructure security, and explore how PKI, cryptography, and monitoring all come
together in protecting sensitive systems. Most importantly, it gave me a clear vision of
what it means to design secure environments that align with modern cybersecurity
principles like Zero Trust.

6|Page
Chapter1/Organization and Project Overview :

7|Page
Introduction :
This chapter will outline the internship context and provide the central aims of the project
which focuses on protections of Public Key Infrastructure (PKI) against advanced attacks. It
will introduce DXC Technology and relevance of the operation and strategic importance of
the Moroccan branch as a key nearshore delivery centre in the EMEA region, covering the the
technical requirements of the project and relevant cybersecurity practices compilance.

I. Part1 : Organizational Background

1. DXC Technology Morocco :
DXC Technology, an American IT services company, was formed in 2017 from the merger of
CSC and HP Enterprise Services. Headquartered in the United States, DXC Technology has
more than 5,900 employees in over 70 countries.

Figure : Global Reach and Key Achievements

DXC Technology (NYSE : DXC) is a global leader in IT services, helping businesses run
their mission-critical systems while modernizing IT, optimizing data architectures, and
ensuring security and scalability across public, private, and hybrid clouds.
Trusted by the world’s largest companies and public sector organizations, DXC drives
performance, competitiveness, and customer experience across IT estates.

8|Page
 Figure1 : Headquater DXC Morocco
DXC Technology Morocco, a joint-venture between DXC Technology and Morocco's Caisse
de Dépôt et de Gestion (CDG), is a strategic nearshore delivery center based at the
Technopolis business park in Rabat. The center provides cost-effective, high-quality IT
services to EMEA customers in Europe, the Middle East, and Africa. Specialized in a range of
services spanning IT service management, cybersecurity, cloud operations, business process
services, and application development, DXC Morocco plays a key role in facilitating digital
transformation and operational excellence in the region.
At DXC Technology, I gained experience in the Cybersecurity team, focusing on the Security
Operations Center during my internship. Through this experience, I gained hands-on expertise
in tracking, detecting, and addressing cyber threats in real time. Collaborating with a skilled
and proactive team, I gained valuable knowledge in incident response, log analysis, and
security monitoring tools. Through this internship, I gained a deeper insight into the vital role
cybersecurity plays in securing business operations and preserving client trust.

Figure2 : Organizational chart

2. Key figures and activities :
In 2007, DXC Maroc, which is also referred to as Entreprise de Services Sociaux CDG, was
founded. The company is a partnership between DXC Technology (51%) and CDG (49%),
and has a total of 1,200 employees across three locations in Morocco (Technopolis, Hay Riad,
and Casa Nearshore). Public and private organizations in Morocco are supported by DXC
Technology Morocco with their digital transformation through the use of technologies such as
managed services, data management, application modernization, business intelligence,
mobility, business operations, security, and consulting.

9|Page
The table below presents the legal and organizational Information of DXC Technology in
Morocco :

Figure3 : Legal and Organizational Information

 Major Activities of DXC Morocco :

IT Infrastructure Management : Covers servers, storage, cloud infrastructure, and
network management.
Application Services : Offering software development, modernization, and
maintenance.
Service Desk and Technical Support : Offering 24/7 multilingual IT support.
Cybersecurity Operations : Conducting threat monitoring, vulnerability scans, and risk
management.
Cloud Services : Capabilities in deploying and managing public, private, and hybrid
cloud solutions.
3. Expertise and Commitment to Cybersecurity :

DXC Technology Morocco positions cybersecurity as a core pillar of its integrated services to
assist public and private institutions in safeguarding their digital territories. The organization
offers comprehensive security services that safeguard sensitive information, critical
infrastructure, and digital resources from sophisticated cyber threats.
 Consulting and Audit :
 Security Consulting : DXC’s experienced consultants support clients in assessing
their current cybersecurity posture including gaps and tailoring protective measures
appropriate to the client’s risk environment.
 Security Audits : Rigorous audits are done to evaluate the adequacy of the security
measures put in place, and assess compliance with relevant international policies and
regulations.

10 | P a g e
  Risk and Compliance :
 Cyber Risk Management Services : To help in identifying and quantifying
possible threats, DXC conducts risk assessments along with vulnerability scans
and penetration tests on a regular basis. These activities enable the organizations
to proactively devise effective strategies towards mitigation.
 Compliance Support : DXC assists its clients to become and remain compliant
with the key regulations such as GDPR, HIPAA, ISO 27001, NIST, and EVA, by
providing regulatory guidelines and implementation recommendations.
 Monitoring and Incident response :
 Security Operations Center (SOC) : DXC has SOC that works 24/7. SOCs
undertake monitoring all the time, provide real-time detection of threats, and
provide response for problems to make sure that there is a timely reaction to
security infringements and taking advantage of loopholes in systems.
 Advanced Threat Protection : With the aid of Artificial Intelligence (AI)
and Machine Learning (ML), DXC uses predictive defensive mechanisms to
detect and destroy Advanced Persistent Threats (APT) before any damage is
incurred.
4. Security Approach and Evolution at DXC Technology

DXC Technology follows Zero Trust Security Model of never trust, always verify. The
company's security approach includes the following key principles :
Identity and Access Management (IAM) : Ensuring the strict control of access to data and
systems.
Data Protection : Applying encryption to sensitive data in both states, at rest and in transit, to
dissuade unauthorized access.
Threat Intelligence and Analytics : Employing dynamic surveillance, AI-influenced data
analysis, and predictive simulation for preempting and reacting to threats before they happen.
Cloud-native Security : Providing security solutions for hybrid, multi-cloud, and edge
computing.
Continuous Innovation : Staying relevant with new technologies like IoT, AI, 5G for better
security. Strategic Partnerships.

11 | P a g e
II. Part2 : PROJECT CONTEXT AND REQUIREMENTS
STUDY
1. Background of the Internship and Project Objectives

After two intensive years of study in cybersecurity, I began to develop a passion for defensive
security and Security Operations Centers (SOC). It was fascinating to observe that these were
examples of environments in which practitioners spent their days working through the
challenges of protecting critical infrastructure from the advanced threat actors that target it.
The SOC project allowed me to take more theoretical considerations and present them in a
way that is less theoretical and more applied, while still building my knowledge of topics
relevant to SOC operations. Specifically, it allowed me to increase my knowledge in PKI,
certificate validation, attack simulation, and analysis of logs. Through the decision to take on
this project, I was aiming to increase my technical skillsets that are similar to those in SOA
environments, to align my education with the long-term objective of continuing to work and
manage security in SOC environment - where PKI is a critical part of securing identities,
establishing trust, and adult safe communication across and between systems.

Figure4 : The SOC team

My objective was to understand the functioning of PKI systems from both practical and
theoretical perspectives, focusing on securing them and assessing their security against new
cyber threats.
I configured two distinct two-tier PKI environments to achieve this one on Linux using
OpenSSL and another on Windows Server with Active Directory Certificate Services.
Notably, since PKI serves as a basis of digital trust ensuring secure communication, user

12 | P a g e
authentication and data integrity, I was fortunate to learn and examine both the operation and
security of a critical infrastructure component of modern IT environments.

2. Problematic : Securing Public Key Infrastructure (PKI) Against

Advanced Threats

Public Key Infrastructure plays an important part in protecting the privacy, integrity, and
authenticity of digital communications. However, PKI systems can be attractive targets for
attackers with the aim of compromising trust, by taking advantage of insecure configurations,
trademark poorly secured certificate authorities, or less than optimal revocation processes.
This project aimed to overcome the key challenge :
« How to deploy, harden, and continuously monitor a Public Key Infrastructure safely in
Linux and Windows Active Directory environments with ELK Stack for anomaly detection
and protection against advanced threats to certificate trust and validation ? »
This research was performed using two distinct two-tier PKI setups : one operating on Linux
and the other on Windows.By adopting optimal PKI security measures, I successfully
validated revocations through OCSP responder and OCSP Stapling. The evaluation of
system resilience involved executing simulated attacks, including OCSP Relay with
OpenSSL, and privilege escalation caused by AD CS misconfigurations ESC1/7. By
integrating a SIEM solution with the ELK Stack, live monitoring of the infrastructure was
achieved, facilitating rapid identification of security breaches or irregular activities.
3. Project Planning and Timeline :
The project timeline below shows the planned stages of the internship in conjunction with the
literature review, infrastructure design and setup, security testing, security hardening,
monitoring configuration, and final documentation. The detailed planning allowed for an
orderly process and time management and scheduling of work during the internship.
Table 1 below summarizes the different phases of the planning process and the outcomes of
the project.

#ID Task Name Start Date End Date

0 Project Start 04-Feb
1 Documentation 04-Feb 20-Jun
1.1 PFE Report Drafting 04-Feb 20-Jun
2 PKI Design & 05-Feb 12-Feb
Architecture
2.1 PKI Architecture 05-Feb 07-Feb

13 | P a g e
 Planning
2.2 Component Selection 08-Feb 12-Feb
& OS Setup
3 Linux-Based PKI 13-Feb 23-Feb
Deployment
3.1 Offline Root CA 13-Feb 15-Feb
(OpenSSL)
3.2 Subordinate CA Setup 16-Feb 18-Feb
3.3 Web Server 19-Feb 21-Feb
Integration (Apache +
HTTPS)
3.4 OCSP Responder 22-Feb 23-Feb
Setup
4 Windows-Based PKI 24-Feb 03-Mar
Deployment
4.1 Offline Root CA (AD 24-Feb 26-Feb
CS)
4.2 Subordinate CA & IIS 27-Feb 01-Mar
Integration
4.3 OCSP Responder 02-Mar 03-Mar
(Windows Role)
5 OCSP Stapling 04-Mar 07-Mar
Configuration
6 Security Testing 08-Mar 18-Mar
(Linux & Windows)
6.1 MITM, OCSP Replay 08-Mar 12-Mar
(Linux)
6.2 Template Abuse 13-Mar 18-Mar
(Windows)
7 PKI Hardening 19-Mar 29-Mar
7.1 Linux 19-Mar 24-Mar
TLS/Apache/OpenSSL
Hardening
7.2 Windows AD CS & IIS 25-Mar 29-Mar
Hardening
8 SIEM Integration & 30-Mar 10-Apr
Monitoring (ELK)
8.1 Log Forwarding & 30-Mar 03-Apr
Filebeat Setup
8.2 Dashboard & Alert 04-Apr 10-Apr
Rules (Kibana)
9 Final Testing & 11-Apr 19-Apr
Documentation
9.1 Validation of Security 11-Apr 15-Apr
Events
9.2 Screenshots, Scripts, 16-Apr 19-Apr
Config Files
10 Final Report and 20-Apr 31-May
Recommendations

14 | P a g e
 X Project End 23-Jun

Table1 : Planing Phase

4. Requirements Study and Best Practices :

Implementing security for a Public Key Infrastructure (PKI) requires a layered approach
including verification procedures, hardening procedures, as well as continuous monitoring.
Tools and frameworks are available to assist organizations in thier PKI deployments.

4.1 Commercial PKI Management and Monitoring Solutions :

 GlobalSign : GlobalSign is a trusted global provider of digital identity and security

solutions, delivering cloud signatures, OCSP responses, digital certificates, and trusted
timestamps to users worldwide. Their services support secure communication, identity
verification, and automation of encryption and authentication processes for businesses,
cloud platforms, and IoT ecosystems.
 Windows AD CS : Active Directory Certificate Services (AD CS) on Windows
Server provides a scalable and secure platform for creating, managing, and validating
digital certificates.
 DigiCert : is the world's premier provider of high-assurance digital certificates
providing trusted SSL, private and managed PKI deployments, and device certificates
for the emerging IoT market.

Figure5 : Commercial PKI management solution

4.2 Open-source Tools and Frameworks :

 EJBCA (Enterprise Java Beans Certificate Authority): A feature-rich open-source

CA that offers features such as X.509, OCSP, CRL, and CMS.
 OpenSSL : Necessary for performing manual certificate creation, signing, and
configuration of encrypted connections. Perhaps the most commonly used software
related to PKI in Linux environments.
 OpenXPKI : OpenXPKI is a powerful, enterprise-level PKI solution designed for
flexible and scalable management of X.509v3 certificates. It offers a user-friendly web

15 | P a g e
 interface, customizable workflows for certificate issuance, renewal, and revocation,
and supports full automation through standard protocols and a versatile API making it
ideal for streamlined certificate lifecycle management.

Figure6 : Open-Source Tools Certifications creations

 OCSP Responder with Apache or NGINX : Used to configure OCSP services to

provide real-time updates to certificate status checks.

Figure7 : Opens-source Servers

ELK : An open-source SIEM solution called the ELK Stack consists of Elasticsearch,
Logstash, and Kibana. In cybersecurity, it is extensively employed for log collection, analysis,
and visualization.
WAZUH : Is open-source SIEM platform providing securtiy tools for users like intrusion
detection, log analysis, identifying vulnerabilities and file integrity and monitoring,
compliance.

Figure8 : SIEM Open-source

16 | P a g e
Conclusion :

This chapter has also offered an extensive examination of the internship’s organization,
clarified the goals of the project and clearly recognized the security issue central to this
project enhancing PKI against emergent threats. In addition to examining DXC Technology’s
organization, centering on its operation in Morocco, and delineating relevant practises and
cybersecurity expectations, we have created the groundwork for the next technical phases of
work in the project. This contextual and strategic analysis will ensure that the project meets
the organization’s requirements and conforms to established security expectations.

17 | P a g e
Chapitre2 / State of art and Best practices :

Introduction :

18 | P a g e
The need for secure communications and trusted identities in digital communications is more
important now than ever. This chapter introduces Public Key Infrastructure (PKI) as an
architecture to protect confidentiality, integrity, and authenticity of digital communications. It
includes a discussion of some of the base concepts of PKI architecture and design, and some
of the security mechanisms that use PKI, specifically Certificate Revocation Lists (CRLs), the
Online Certificate Status Protocol (OCSP), and OCSP Stapling. We will also cover important
implementation standards and guidelines like RFC 5280, RFC 6960, TLS 1.3, and the
recommendations issued by NIST, ISO/IEC, and ANSSI.

Part1 : Public Key Infrastructure (PKI) Fundamentals :

1. PKI Components :

A Public Key Infrastructure relies on several vital components that function together to
secure and authenticate digital communications. The main components involved are the
Certification Authority, Registration Authority, certificate repository, and archive
system. The users within a PKI are typically categorized into certificate holders, who
receive certificates, and relying parties, who verify and trust those certificates.
Attribute Authority may optionally be incorporated to assign specific attributes to users.
The role of the CA is akin to that of a digital notary, ensuring the identities of entities
participating in digital exchanges, including secure email and electronic transactions, are
verified and certified.
The process of verifying identities plays a critical role in creating trust between the
communicating sides. Digital certificates function like photo IDs or PINs, providing
authentication in the digital just as they do in the physical world.
The Registration Authority (RA) helps the Certification Authority (CA) by checking
and confirming a user's identity before any certificate is issued. After the identity is
verified, the CA creates and signs a digital certificate that includes things like the user’s
public key, name, how long the certificate is valid, and its own digital signature. These
certificates may also mention what they should be used for.

19 | P a g e
All valid certificates and revoked ones are kept in a central place called a repository,
which also includes Certificate Revocation Lists (CRLs). This helps users (relying
parties) check if a certificate is still valid or if it has been canceled. There’s also an
archive that keeps old
certificate information. This is useful in case of disagreements, as it lets people check if a
digital signature was still valid at the time it was used. The CA is in charge of canceling
certificates when needed and updating the CRLs so everyone knows which ones should no
longer be trusted.

Figure : PKI Components

1.1. Certification Authorities (CA) :

Certification Authorities play a pivotal role in all PKI systems. CA consists of hardware,
software, and personnel that perform four key functions, issuing and signing digital
certificates, managing and publishing certificate revocation lists, providing access to
current certificates and CRLs, and archiving expired certificate information for future use.
CA has the ability to issue certificates to both individuals and other CAs. This step
validates that the certificate recipient holds the private key linked to the public key
embedded in the certificate, might also contain additional information, such as email
addresses or usage policies.
Each certificate and CRL is signed using the CA's private key and contains its name. If
users trust the CA and confirm its signature with its public key, they can rely on the
certificates it issues. Due to this, CA private key security is crucial, often employing
secure cryptographic hardware that follows standards such as FIPS140.

20 | P a g e
 1.2. Registration Authority (RA) :

Registration Authority (RA) serves an important role in the issuance of a certificate as a

trusted agent between the end-user and the Certification Authority (CA). An RA's main
responsibility is to authenticate the identity and information of the entities applying for the
digital certificate. The information may be official documents, employment records, or
verification by a third-party source (internal departments such as HR, Compliance
Auditor). For instance, the employee's certificate (Credentials) may indicate certain
authorization rights such as the ability to sign contracts for a limited amount.
Functionally, an RA consists of hardware, software, and operational personnel like a CA,
except there are usually many instances of an RA, which can usually be operated by one
person. Each CA has a list of RAs that it trusts or has accredited to verify and send a
certificate request. An RA has a name and a public key that uniquely identifies it, and the
CA is relying on the RA's digital signature on the certificate request to trust the
information that the CA is receiving. Therefore, it is important to secure the RA's private
key and RAs are encouraged to implement cryptographic modules that meet the FIPS 140
standard to provide an additional level of security.

1.3. Validation Authority(VA) :

Validation Authority (VA) is an important piece of the Public Key Infrastructure, providing
near-real time validation of the revocation status of digital certificates. On its own, a VA is
not a certificate issuer or a trust anchor, but without it, an organization cannot guarantee that
the presented certificate is valid or trusted, as a VA will use their own revocation data
provided by the Certification Authority (CA). VA verifies the certificates based on a policy
that defines how clients should consider certificate status (valid or revoked). VA can reside
either internally hosted by the entity managing the PKI or externally hosted by a trusted third-
party organization, but both options will help provide assurance of trust for secure
communications.
To perform this role, VA's use two common standards :
Certificate Revocation Lists (CRLs), defined in RFC 5280, and Online Certificate Status
Protocol (OCSP), defined in RFC 6960. CRLs are static lists of revoked certificates, and
OCSP allows you to query them live. Implementing a VA into the PKI means organizations

21 | P a g e
will be able to greatly improve trust and responsiveness in their security infrastructure. In
situations such as finance, e-government, and digital commerce, where timely validation and
revocation checks act as deterrents to misuse and enable secure transactions, implementing a
VA will significantly improve their safety.
1.4. Certificate lifecycle :
Digital certificates are at the core of secure online communication, providing trust,
authenticity, and encryption across digital ecosystems. Managing these certificates effectively
is critical to ensuring uninterrupted service, regulatory compliance, and defense against cyber
threats. The certificate lifecycle encompasses several essential stages from issuance and
validation to renewal, revocation, and auditing each playing a vital role in maintaining the
integrity of digital identities. The image below visually represents this comprehensive
lifecycle, highlighting the key processes required for successful certificate management
within any secure infrastructure

Figure : Certificate Lifecycle management

2. OCSP vs CRLs Revocation mechanisms :

This section will detail the key protocols employed by the various elements within a Public
Key Infrastructure.Users can leverage these protocols to access and interact with the various
services supplied by the PKI.

22 | P a g e
 Figure9 : OCSP vs CRLs

2.1. CRLs :
A Certificate Revocation List (CRL) is a record-maintained by a Certification Authority
(CA) of digital certificates that have been revoked before their expiration date (no longer
trustworthy). Web Server consult CRLs to determine whether the certificates used for
encrypted communications are still valid. The revocation can occur for various reasons,
including suspected key compromise, mistakes in the issuance of the certificate, or violations
of CA policy. In an effort to facilitate more timely and effective checking of certificate status,
the Online Certificate Status Protocol (OCSP) has also been widely adopted.
OCSP allows clients to proactively query the status of individual certificates in real time
instead of periodically updating the status in CRLs, which is generally more time consuming.
OCSP has been adopted by many recent versions of many cryptography systems to improve
security in Public Key Infrastructures.
2.2. OCSP :
The Online Certificate Status Protocol is an Internet protocol designed to check the
status of an X.509 digital certificate. OCSP is defined by the IETF in RFC 69601. The
protocol serves as an alternative that mitigates some of the difficulties related to
Certificate Revocation Lists in a Public Key Infrastructure. OCSP messages, encoded
in ASN.1, are adaptable for transmission over a range of application protocols. As
OCSP operates through request and response messages, OCSP servers are designated
as OCSP responders.
 Advantages of OCSP over CRLs :
There are several advantages to using the Online Certificate Status Protocol (OCSP) over
a traditional Certificate Revocation List (CRL), particularly the following :
OCSP provides users with the most current status of a certificate, whereas CRLs may be
outdated by the time they are consulted. With OCSP, clients do not need to download the
entire CRL to verify a certificate's validity, when CRLs contain numerous entries, this
results in significant savings in processing time and reduces bandwidth consumption.
Additionally, OCSP eliminates the need for clients to parse and interpret large CRLs
independently, there by simplifying the certificate validation process and reducing the
computational load on the system, ultimately conserving resources.
23 | P a g e
 Additionally, OCSP responders also create models of businesses, compensating certificate
issuers when you pay for a status issue, as opposed to passing that cost on to the client.
Lastly, CRLs may be compared to a "blacklist" maintained by banks, which they do not
want to disclose publicly due to privacy concerns about those disqualified customers.
OCSP has a more private and lower-overhead means of validating a certificate's status,
which minimizes the risk of exposing personal information, as well as the need to risk
identifying oneself as a potential identity.
Feature OCSP CRL

Validation Time Real-time Periodic based on update

frequency
Network Dependency Requires online checking Can validate from cached
CRLs offline
Latency Overhead Each request has some Local CRL check has
latency for network round minimal latency
trip
Scalability Can have scalability Distributed CRL caches
challenges on CA side avoid centralized load
Revocation Propagation Revocations blocked Latency until next CRL
Delay immediately publication
Implementation Responder deployment for Significant CRL
Complexity CA management overhead
Bandwidth Overhead Very lightweight requests Can have bloated
downloads for large CRLs
Security Considerations Spoofing, DoS attacks, Spoofing CRLs, ensuring
privacy leaks authenticity
Privacy OCSP leaks info to CA on CRLs avoid active info
each request leakage

Browser/Client Support Supported by all major Also universal standard

browsers support
Failover Capabilities OCSP secondary CRL acts as fallback if
mechanism if CRL lapses OCSP fails
Table : CRLs vs OCSP
 Structure of OCSP request :
OCSP communication operates on a request-response basis, where the servers handling these
queries are known as OCSP responders. Within the protocol, a client sends a request to the
OCSP responder asking for the status of one or more certificates. The OCSP responder then
acknowledges receipt of the OCSP request and verifies the validity of the certificates and
returns a response to the requesting entity :
 RFC 2560 explains that an OCSP request will include.

24 | P a g e
  The version of the protocol.
 A service request with the type of request services being requested.
 The certificate being requested and all certificates in question.
 Optional extensions, which if requested, the OCSP responder may process in order to
provide enhanced features or gain additional information.

Figure10 : Components Request OCSP

Upon receiving an OCSP request, the responder checks that :
 The message is properly formatted.
 It’s configured to provide the requested service.
 All necessary information for processing is included.
If any of these checks fail, the responder returns an error. Otherwise, it sends a final status
response.
OCSP responses fall into three categories :
 Good : The certificate is valid and not revoked.
 Revoked : The certificate is no longer valid, either temporarily or permanently.
 Unknown : The responder has no information about the certificate requested.

25 | P a g e
 Figure11 : Components OCSP response

 The delegation of OCSP signing authority :

The key used to sign the certificate status information must be different from the key that
signed the certificate itself. The certificate issuer explicitly delegates the authority to sign
OCSP responses to the OCSP responder. This delegation is done by issuing a certificate to
the responder that includes a specific extendedKeyUsage value indicating OCSP signing
rights.
This certificate must be directly issued to the responder by the issuing Certificate Authority,
as specified in RFC 2560.
3. OCSP Stapling : performance and privacy improvements for HTTPS
OCSP stapling is a privacy-preserving feature of the TLS protocol, which allows the web
browser to determine the revocation status of a server’s certificate without making an
additional request to an OCSP responder. Rather than each client contacting the certificate
authority (CA) to determine a certificate is valid, the web server contacts the CA OCSP
responder periodically and stores the response locally. When a client begins a TLS handshake,
it indicates it supports OCSP stapling by including a status_request extension in the
ClientHello message. The client can provide a trusted OCSP responder in the process as well.
After the server receives the ClientHello handshake request that includes the status_request, it
sends back its certificate, any intermediate certificates, and the cached OCSP response in its
TLS handshake response.

26 | P a g e
 Figure12 : OCSP Stapling
OCSP stapling has a number of advantages from a security and performance perspective. By
fetching the OCSP response ahead of time, the server can send a pre-fetched OCSP response
to the client, which avoids the need to contact the certificate authority directly, which lowers
latency and page load time. This also improves user privacy as the CA cannot trace client
connections. Furthermore, OCSP stapling also protects against some attack vectors like man-
in-the-middle attacks and replay attacks, especially when implemented with certificates of
short lifespan. With more websites acting to implement the OCSP stapling technology into
their site more and more websites and browsers are transforming the performance of HTTPS
in a secure and efficient manner.
Part2 : Security Standards and Best Practices
1.Relevant RFCs :
1.1. RFC 5280 (X.509 Certificates)
RFC 5280 is a fundamental standard for the internet, outlining the technical details of the
X.509 Public Key Infrastructure and the related Certificate Revocation Lists.Issued by the
Internet Engineering Task Force, it details the methods for creating, issuing, and verifying
digital certificates to maintain secure communication between universal resource identifiers
and systems. RFC 5280 is more than a technical document, its essential to modern internet
operations activities, It explains the way browsers, servers, and applications manage
identities, as well as how they encrypt and protect data.

27 | P a g e
 Figure : Structure of X.509 Certificate

At the heart of RFC 5280 is the X.509 certificate, which is akin to a digital digital ID that
identifies and verifies people, websites, or organizations on the Internet. These certificates
aim to associate a public cryptographic key to an identity, and they are issued and signed by a
trusted certificate authority. Each certificate contains a number of significant fields including
the owner of the certificate's name, the public key, a unique serial number, an expiration date,
and a digital signature to prove that it has not been tampered with. There are many other
fields, known as extensions, such as Key Usage or Basic Constraints, which indicate how the
certificate can be used i.e. securing a website, or signing other certificates.
RFC 5280 describes how to build and trust a chain of trust from root Certificate Authority
authority, down to the user end certificate, with requirements for certificate validation using
CRLs or OCSP. This is the framework for secure web browsing, email encryption, and digital
signatures. It ultimately revolves around RFC 5280 and the X.509 Standard to form a
trustworthy secured digital space.
1.2. RFC 6960 (OCSP Protocol)

RFC 6960 outlines the Online Certificate Status Protocol (OCSP) is a mechanism for
checking the revocation status of X.509 digital certificates in near real-time. OCSP is defined
by the IETF and is intended to provide a more efficient and quicker way to obtain revocation
status than traditional Certificate Revocation Lists (CRLs). Rather than downloading large
CRLs, a client will query an OCSP responder with lightweight request and will receive a
response

28 | P a g e
Indicating if the certificate status is "good","revoked", or "unknown". The real-time
interaction with a responder can lead to a reduction in latency compared to CRLs and is a
great feature in abandwidth limited or performance sensitive situation where speed and
efficiency are a critical factor.
RFC6960 also improves PKI security in the way we can verify certificate revocation quickly
and accurately. When a certificate is revoked, either from key compromise to certificate
misrepresentation, OCSP allows us to respond quickly, helping to ensure that clients cannot
trust revoked certificates. It also provides signed responses and replay protection against
spoofed content that could compromise the integrity of the revocation data. As digital trust
becomes more valuable, RFC6960 will be essential in providing reliable and validated
certificates.
2. Recommended Cryptographic Settings :
2.1. Algorithms : RSA-4096, SHA-512, ECDSA
 RSA (Rivest–Shamir–Adleman) :
RSA is an old and popular form of public-key cryptographic algorithm. It is based on the
difficulty of the mathematical factorization of large prime numbers. It protects data by using
asymmetric encryption and by creating digital signatures. RSA-4096 has a key size of 4096
bits and very strong security and is not subject to brute-force attacks using current technology.
Because it has been around for so long and has proven itself to be secure, RSA is a reliable
mechanism for encrypting sensitive information and as a mechanism for verifying digital
identities that are part of a PKI system.
 SHA-512 (Secure Hash Algorithm 512-bit) :
SHA-512 is part of the SHA-2 family of cryptographic hash functions. It accepts input of any
length and produces a fixed hash output of 512 bits. SHA-512 is typically used to ensure that
data is intact and has not been altered, and it will create a unique hash for every unique input
and will catch any changes in the data. It is very resilient to collisions which are defined as
finding two different inputs that hash to the same value, as well as a pre-image attack where
the potential attacker must find an input that matches a value that has already been hashed. All
of these properties of SHA-512 make it very valuable for the construction of digital signatures
and certificates with strong assurances of integrity and authenticity.
 ECDSA (Elliptic Curve Digital Signature Algorithm) :
ECDSA is a public-key signature scheme founded on elliptic curve cryptography principles,
It is known as a « lightweight » signature scheme because it offers equivalent security to RSA
but with much smaller keys, usually approximately 256 bits, Therefore, ECDSA facilitates
29 | P a g e
faster signing processes, more compact signatures, and decreased demands on storage and
bandwidth. In resource-limited settings like mobile devices and IoT, this approach is
increasingly being adopted due to constraints in memory and processing capabilities.
ECDSA is also preferred in applications that require high performance and efficiency, Its
increasing adoption indicates a rising need for cryptographic solutions that are both secure
and efficient.
2.2. Protocols : Enforcing SSL /TLS
TLS 1.3 represents a true evolution in the security and performance of digital communication,
adding significantly stronger cryptographic methods without sacrificing performance. TLS 1.3
is the most current major version of the Transport Layer Security protocol, it presents
significant improvements over previous versions by removing features that contributed to
vulnerabilities in the protocol, such as static RSA key exchange and weak hash algorithms.
The protocol introduces a true advancement with security improvements, including required
use of forward secrecy, which mutes the cryptographic payment of compromising long-term
private keys since past encrypted sessions are still protected. Overall implementation of TLS
1.3 in PKI-based architecture greatly reduces your attack surface while subsequently
boosting performance via low latency and speedy handshakes creating secure connections.

Figure : TLS Versions

Equally important is cipher suite hardening, which are all directly applicable to the security of
TLS sessions. There are legacy ciphers like RC4 (a stream cipher with known bias and
statistical attacks), DES (a 56-bit key that can be brute-forced), and 3DES (a kludge to
make DES secure that is obsolete, weak, and ineffective) that are no longer acceptable and
should be disabled. Instead, you would use AES-GCM (Advanced Encryption Standard in
Galois/Counter Mode), a robust encryption cipher, which incorporates authentication,
providing confidentiality and integrity. Having strong, properly configured cipher suites
mitigates the risk for downgrade and man-in-the-middle attacks, and, most importantly,
enables you to remain compliant with any recent protocol security standards from NIST or
other accredited and relevant organizations such as ANSSI. In PKI-based infrastructures,

30 | P a g e
secure TLS settings and strong cipher choices are necessary to establish reliable trust in
encrypted end-to-end communication.
3.Security Guidelines and Compliance
3.1. NIST SP 800-57, 800-52
The National Institute of Standards and Technology (NIST) publishes a series of Special
Publications to help federal agencies and private entities in implementing secure
cryptographic systems. NIST SP 800-57 provides detailed recommendations for
cryptographic key management, including how to securely generate, store, distribute and
retire cryptographic keys. It considers the management of the complete key lifecycle, with
consistent and secure practices, to manage the risk of key compromise or other misuse.

Furthermore, NIST SP 800-52 identifies secure implementation practices for the Transport
Layer Security (TLS) protocol. It defines minimum and recommended requirements for a
TLS configuration that follows federal security policy. Publications from NIST and the NSA
consistently recommend using TLS 1.2 or better, and recommend TLS 1.3 as a best practices
because of the security and performance benefits it brings. By following these
recommendations, organizations can ensure compliance with U.S. regulatory requirements
while building out their digital infrastructure security, reliability, and interoperability.
3.2. ISO 27001 Controls for PKI
ISO/IEC 27001 is a globally recognized standard that establishes the foundation for
developing, implementing, maintaining, and continuously improving an Information Security
Management System (ISMS). Annex A outlines a comprehensive set of security controls
aligned with ISO/IEC 27002 that can be used to measure compliance. Number of these
controls are directly related to securing Public Key Infrastructure, PKI operations, such as
management of digital certificates and cryptographic assets.

31 | P a g e
The ISO/IEC 27001 standard specifies key domains to address regarding PKI processes, such
as access control (A.9), cryptographic protection (A.10) and operational security (A.12).
These domains are essential in protecting PKI processes as they allow key lifecycle
management safely and create consistent enforcement of the encryption policy organization-
wide.
 A.10.1 – Cryptographic Controls requires organizations to implement policies that
manage cryptography, including the choice of algorithms, key lengths, and protocols
such as TLS. It requires the secure creation, dissemination, safeguarding, and
invalidationofcryptographickeys fundamental tasks in any PKI implementation.
 A.9 – Access Control employs authentication techniques that leverage digital
certificates, including certificate-based access for users to vital systems.
 A.12.6.1 – Technical Vulnerability Management guarantees that organizations
consistently oversee cryptographic libraries and certificate setups to reduce the risk
posed by identified vulnerabilities.

Conclusion :
In this chapter we have described the particulars of Public Key Infrastructure, and its
importance in securing digital communications. We have also covered the fundamental
components of PKI, being certificates, Certificate Authorities, trust relationships and perhaps
most importantly, revocation mechanisms particularly CRLs and OCSP.Additionally, we
demonstrated the significance of OCSP Stapling from a performance and security
perspective. By following recognized international standards and best practices from various
RFCs, TLS 1.3, and other organizations like NIST and ANSSI, PKI can be implemented
securely and effectively. When these basic concepts are established. Organizations can
reinforce trust, satisfy regulatory compliance and facilitate a resilient security posture.

32 | P a g e
Chaptre3 : Linux Based PKI Infrastructure (Openssl) :

33 | P a g e
Introduction :
The chapter describes the architecture and deployment of a Public Key Infrastructure (PKI)
using open-source software on a Debian-based Linux system. It implements a two-tier
architecture that is modular, with a Secure Root CA that is offline and an Intermediate CA
that is online. The PKI uses OpenSSL for certificate provisioning and management, Apache2
for https, and an OCSP responder for real-time status checking of certificates. The
deployment also contained real-world use cases of issuing web server certificates and using
OCSP stapling to enhance the security of the https server.
Once the PKI is deployed, the chapter provides recommendations to enhance the overall
security and integration of continuous monitoring for operational visibility. The PKI
environment also enables the simulation of real-world threats, including denial-of-service
(DoS) attacks targeting the OCSP server. These simulations will provide evidence of the
architecture's robustness and identify weaknesses and opportunities to improve PKI
safeguards.

Part I : Architecture Design and Implementation :

1.Architecture Design and Technology Stack :
1.1.PKI Architecture overview :
The PKI infrastructure utilizing a Linux-based operating system developed a hierarchical
structure utilizing a trust model that considers security, modularity, and operational
efficiencies. Our architecture contains two tiers where there is an offline Root Certification
Authority (Root CA) and online Intermediate CA. This architecture cannot be argued to be
best practice in PKI deployments, along with separating longer term trust anchors from daily
operations of issuing certificates, significantly reduces the attack surface that could be
exploited. In this infrastructure, the Root CA is fully isolated (air-gapped) from the network.
The Root CA is responsible for signing and issuing the Intermediate CA certificate and
providing Certificate Revocation Lists (CRLs). The Intermediate CA is responsible for
issuing and revoking end-entity certificates web server, internal application.
In addition to the PKI, an OCSP (Online Certificate Status Protocol) responder component is
integrated within the PKI and provides a means for verifying the status of certificates at any
moment in time. An instance of an Apache2 web server with HTTPS and OCSP Stapling is
34 | P a g e
provided as an example of certificate access. Overall, security hardening is enforced on all
services, including TLS configuration. ELK utility is integrated for monitoring logs, alert,
anomaly detection, and audit compliance.

The figure below illustrates the components of the PKI and the communication flows.

Figure :2-Tier PKI Architecture

1.2. Tooling and OS Selection : Kali Linux, OpenSSL, Apache2, and ELK Stack
Kali Linux was selected as the operating system because of its strong emphasis on security, a
wide range of built-in security tools, and an active, supportive community. Its frequent
updates and hardened features make it a solid choice for running sensitive infrastructure like a
PKI, especially in settings where thorough penetration testing and security audits are
important.
For cryptographic operations, OpenSSL was preferred because of its comprehensive and
flexible tools, broad industry usage, and ability to adapt to various needs. OpenSSL covers all
our requirements, generating keys, issuing certificates, signing them, and revoking
certificates. Since OpenSSL is open source, it offers transparency and the ability to modify it
freely according to project requirements.

35 | P a g e
Apache2 was used as the web server because it’s reliable, supports many modules, and works
with HTTPS and OCSP stapling. This ensures secure and efficient communication for
validating certificates and serving web content, helping to boost both the security and
performance of the PKI.

2. Establishing a Secure and Scalable PKI Infrastructure :

The implementation of a PKI is dependent on the needs of the organization. In our project we
first create the Root Certificate Authority (CA) called marocdxc-pki Root CA, and its Root
CA certificate. This Root CA is the trust anchor and will be kept offline to provide the highest
level of security, with the Root CA we can create subordinate Certificate Authorities that will
have distinct certification roles to suit the needs of the infrastructure. These subordinate CAs
will issue end-entity certificates for such things as email protection, TLS authentication, and
software signing.
Below is a sequence of commands to be executed in a Linux terminal where OpenSSL is
already installed.
2.1. Root CA Creation and Security :

Figure : Setup RootCA Structure (1/2)

To set up the Root Certificate Authority we have defined a systematic means of creating a
structured set of directories for core PKI elements. In this structure we will have four core
elements which are (certs), where all issued certificates are tracked, (crl), where Certificate
Revocation Lists are created and tracked, (newcerts), for tracking newly created certificates,
and (private) for storage of sensitive key material. The private directory is where the Root
CA's private key will be stored and it can be protected with permissions, in this case we will
lock down the permissions to only the user running the CA with (chmod 700) so only trusted
users can access that directory key. Securing this key is paramount because it is the root of
trust for the entire PKI hierarchy.

Figure : Setup RootCA Structure (2/2)

36 | P a g e
Two important files are created in addition to the structure of the directory to help manage
certificates. One of the files is index.txt which stores all items related to certificate issuance,
while the serial file keeps track of certificate serial numbers. In the serial file, the first
number is set to 1000 so that every issued certificate has a different identifier. These files are
essential for tracking and maintaining security standards for the PKI.

Figure : Selfsigned RootCA

This command creates a 4096-bit RSA private key, which is encrypted via AES-256 with a
passphrase. The key file access controls are set to the owner can read, so it may only be read
by that user (chmod 400). Essentially, this will ensure that only authorized personnel has
access to that key and there is protection against unauthorized use or exposure of the Root CA
private key.
Next, we create a self-signed X.509 certificate for the Root CA, which will be valid for 20
years (7300 days). This certificate will be signed using the SHA-256 hashing algorithm,
which has strong collision resistance properties. As part of this process, we will need to input
identification details, including the organization name, country, and common name so that we
can uniquely identify the Root CA. This certificate is the certificate authority which will serve
as the trust anchor of the PKI and establishes the security of all certificates issued under the
PKI.
II.2. Subordinate CA Configuration and Certificate Chaining :
The Intermediate Certificate Authority (CA) was created in the exact same manner as the
Root CA, with a defined directory structure for certificates, private keys, certificate signing
requests, and revocation, and with specifications around access to that information in order to

37 | P a g e
protect sensitive information. A 4096-bit RSA private key was generated, enciphered with
AES-256, and secured by a passphrase for use. After this, a Certificate Signing Request
(CSR) was prepared and submitted to the Root CA for signing, thus creating a trusted
relationship between the two CAs.

Figure : Signing the IntermedaiteCA

This model provides a greater level of security as it does so through issuing certificates
through an Intermediate CA, and thereby maintain the Root CA in an offline state and
removing a risk from the PKI.
II.3. Deployment of OCSP Responder :
The OCSP (Online Certificate Status Protocol) Responder, implemented via the Intermediate
CA within robust security principles. An OCSP signing certificate was first issued by creating
a distinct Certificate Signing Request (CSR), which was then issued by the Intermediate CA.
strong RSA 4096-bit private/public key pair was created that was encrypted with AES-256,
and only allow limited access to it to provide further protection against undesired
compromise.
The OCSP responder provided timely updates to certificate status and improved revocation
speed, while also increasing security compared to traditional CRL methods.

38 | P a g e
 Figure : Signing the OCSP.crt
To test the OCSP responder's operation, we invoked it on port 2560 with the OpenSSL
command line utility, referring to the Intermediate CA's certificate, index file, and specially
designated OCSP signing key and certificate. After starting the responder, we tested it by
querying a previously issued certificate's status.

Figure : OCSP Responder test

The response showed that the certificate status was "good," which means that the OCSP
responder successfully processed all of the requests and provided current certificate
validation. Successfully passing this test indicates that the OCSP infrastructure is operational,
effectively improving the trust and integrity of our PKI deployment by confirming that end-

39 | P a g e
entities can verify the certificate status in real-time. The ongoing operation of an OCSP
service is critical to supporting secure communications and timely revocation status checking.

Figure : Basic operation OCSP Responder OCSP client and server sides

To get an understanding of how OCSP (Online Certificate Status Protocol) works, the
diagram above illustrates the communication between client and server. The client builds,
signs, and sends the OCSP request. The server verifies that the request is valid, checks the
status of the certificate for revocation status, builds and signs a response, and sends it back to
the client. At this point, the client also verifies the response and the process is complete.

II.4. Web Server Apache : TLS Optimization and Certificate Validation Enforcement :
In order to enable secure communication between the client and the web server, we
configured the Apache server to enforce HTTPS using a valid TLS certificate, which we
signed with our Intermediate CA. This configuration guarantees not only confidentiality and
integrity, but also authenticity by chaining back to our Root CA.
II.4.1. TLS Certificate Generation for Web Server :
We made a dedicated server certificate web.crt from our Intermediate CA that we created
prior, this included creating the CSR which stands for Certificate Signing Request, and
signing it with the Intermediate CA, all using OpenSSL.

40 | P a g e
 Figure : Web.csr creation
We create a Certificate Signing Request (CSR) for the web server using the private key of the
web server. The CSR includes the public key as well as the web server's identity (Common
Name, Organization, Country, ).

Figure : Signing the Web.crt

After it has been created, the CSR (web.csr) is signed by the Intermediate Certificate
Authority (CA), to issue the web server certificate (web.crt). The signed certificate provides
the trustworthiness of the server and is provided in the TLS handshake, which occurs during a
HTTPS connection.

41 | P a g e
 II.4.2. Apache HTTPS Configuration with TLS Hardening :
We configured Apache to use the intermediate Certificate Authority's certificate (web.crt)
when we put a configuration file specifically for the virtual host in /etc/apache2/sites-
available/ssl-secure.conf. This virtual host using listen port 443 using SSL. We increased the
security by disabling support TLS 1.0 and 1.1. In other words, we configure the server to
allow only TLS 1.2 and TLS 1.3 connection by using the directive : SSLOpenSSLConfCmd
Protocol TLSv1.2, TLSv1.3

Figure : Apach2 serverWeb Config

This ensures that connection will not be introduced the risks associated the older versions to
protocols. Next, we also configured the SSLCiphreSuite. We enforced our repository to use
only strong ciphers with SSLHonorCipherOrder. This ensures that our types of cipher suites
are strong cryptographically. Thus, our server won't accept weaker algorithms like 3DES and
MD5-based hashes. Both of these hash algorithms are well-known to all be vulnerable to
attacks such as buffer overflows combined their lack hash security. All of this configuration
provides a level of encryption and integrity to our data via HTTPS connections that is
consistent with the current industry standards for security.
42 | P a g e
In order to support HTTPS and the enhanced SSL / TLS configurations, we continue to enable
the appropriate Apache modules, like ssl and socache_shmcb. The ssl module is necessary to
deal with encrypted HTTPS traffic. The socache_shmcb module is needed for the OCSP
stapling capabilities, which involves ability for the server to cache OCSP responses.

Figure : Enabling TLS

After enabling the required modules with the a2enmod command, we restarted the Apache
service to load the new configuration, before checking the service status with systemctl.
Everything appeared to be great, as Apache was running without issue. We now knew that our
hardening was successfully implemented and that the server was performing exactly as
intended.

Figure : Status Apach2

II.4.3. Hosting a Website over HTTPS :

To verify that our HTTPS setup was functioning as required, we deployed a simple test
website with the certificate signed by our intermediate CA. Because the browser did not trust
our custom PKI automatically, we imported both the Root and Intermediate CA certificates
into Firefox’s trusted authorities, which allowed the browser to see the entire certificate chain
to the root and trust it. After going to the site, the secure padlock appeared in the browser, and
checking the certificate details showed everything was set up correctly.

43 | P a g e
 Figure : Deployment Chain.crt(RootCA.crt/Intermediate.crt)

The webpage opened securely over HTTPS and was confirmed by the padlock icon in the
browser. This indicates a TLS session was set up successfully, and the browser validated the
entire certificate chain up to our Trusted Root CA. This verifies that our PKI-based HTTPS
implementation is working correctly.

Figure : Webpage HTTPS

This page establishes that the HTTPS service is well-configured, and that the certificate
provided by our PKI is recognised as properly authentic by the browser. It also demonstrates
the linkage of the components : Root CA, Subordinate CA and Apache web server with TLS
support.

44 | P a g e
The status page for the OCSP server confirms that it is operational and ready to process OCSP
requests. This indicates the infrastructure is properly established to validate the status of
certificates in real-time, and clients can then validate if a certificate has been revoked.

Figure : Status OCSP Server

In addition, the OCSP status page demonstrates that OCSP stapling is configured on the
server. In this case, the server "staples" a valid OCSP response with a time stamp during the
start of the TLS handshake, and the client can use the information provided to validate the
revocation status of the certificate. The OCSP stapling method removes the additional step of
opening a separate connection to an OCSP responder for the client, thus helping to eliminate
latency and possible privacy leaks. It also decreases the risk of failures, if the OCSP responder
is not available. Therefore, it provides faster, more efficient, and more reliable certificate
validation of secure communications.

Figure : Root and Intermediate CA Directory Trees

45 | P a g e
By the end of the PKI Tier 2 deployment using OpenSSL specifically on a Linux system, we
organized all of the cryptographic components in a directory tree structure following industry
best practices. The organized, secured, maintainable directory layout logically separated
certificates, CSRs, CRLs, private keys, and logs. As such, it contained end-entity certificates
(web.crt), OCSP certificates, and full-chains, which is a complete deployment supporting both
the issuance of certificates and the revocation mechanism. The directory tree also
demonstrates the two-tier PKI architecture was established in a successful and secure manner.

Part II : Monitoring, Incident Detection, and Threat Simulation :

1.Logging and Security Monitoring Integration SIEM :

As IT environments grow in complexity, organizations are deploying a wide variety of

security tools like firewalls, intrusion detection systems (IDS), and antivirus programs, all of
which monitor network activity, however, they struggle to detect "unusual" or "suspicious"
behavior. According to the NIST Cybersecurity Framework, organizations should first
understand what their assets are and their possible threats. Then protect information, look for
types of attacks quickly, respond properly, and employ a recovery plan.

However, no analyst can review the thousands of devices, which create a massive amount of
log data, every second to manually assess whether any alerts its impossible. Managing this
volume of information requires significant time and resources. As a result, organizations turn
to centralized platforms called SIEMs to automate security monitoring and easily respond to
threats.

Figure : Cyber Security NIST Framework

46 | P a g e
As mentioned previously, SIEM is the centralized platform for log monitoring. It collects data
from many sources and endpoints, correlates these data in real time, and identifies potentially
suspicious behavior. Several built-in response features can serve to mitigate threats, and the
overall process is summarized through detailed reports and dashboards.

Figure : SIEM Process Flow

The primary purpose of a SIEM is to enable centralized analysis of security logs. In addition,
it provides security-related features like vulnerability detection, threat intelligence, event
correlation, and automated response to attacks or malicious activities. The normal SIEM
architecture offers a variety of critical security services to help protect the organization
effectively.

Figure : Architecture of SIEM

Now that we have understood the architecture of SIEM, we must consider the key metrics that
should be monitored and analyzed during investigations of events so we can identify security
incidents, understand their impact, and determining the appropriate response as shown in
Table below.

47 | P a g e
 S No. Log Source Type Log Source Example
1 Events and logs Raw log, Alert, Event, Windows events,
Syslog, Sysmon, Alarm
2 Network Information Traffic Flow, Sessions
3 Structured Digital Feed Scan, Vulnerability Information
4 Threat Intelligence Indicator of Compromise (IoC) such as IP,
hashes, domain names, URL

Table : Monitoring, Metric and Formats

1.1. Security Monitoring with SIEM : Role of ELK

We accomplished the objective of this project by using the ELK Stack with Filebeat agents as
our SIEM solution to centralize and simplify security monitoring across our PKI environment.
We delivered the ability to collect logs and therefore, monitor in real-time, the CAs, web
server and OCSP server. We monitored the OCSP server because we could track certificate
validation requests, as well as investigate potential unwanted activity. A range of dynamic
dashboards and alerts offered us transparent visibility to our environment, and could respond
quickly to potential threats.

Figure : Architecture SIEM ELK

The ELK Stack is a widely-used, open source set of tools for processing and visualizing logs.
Elasticsearch does fast searches of large volumes of data, Logstash processes or morphs logs
into a usable format, and Kibana enables users to easily create dashboards and alerts. The
usability, flexibility, and scalability of ELK makes it a practical and cost-effective SIEM
solution, especially in environments like PKI, where it is imperative to have visibility, logs,
and the ability to analyze quickly.

48 | P a g e
 1.2. ELK Stack Deployment and Configuration :
To accomplish centralized security monitoring, the first task was to install the Elasticsearch,
Kibana engines, the core of the ELK Stack. The images below show the installation and
execution of this INSTALLATION and EXECUTION.

Figure : ELK Setup

We began the deployment process by first updating the system and installing a few basic
tools, specifically, curl, wget, and gnupg, these tools are necessary for securely downloading
and verifying the Elasticsearch packages. Next, we added the allowed Elasticsearch
repository, we imported the GPG key and updated our package sources. From there, we
updated the package listing, and finally installed Elasticsearch. This was an important part, as
it installed the core engine which will store, and process, all of the logs we will collect later in
our overall monitoring setup.

Figure : Status Elastic

49 | P a g e
After installation, we verified the service was running properly with the sudo systemctl
status elasticsearch command. As indicated from the image, Elasticsearch started
successfully and is active, indicating that the system can receive and index log data. Verifying
the service is running at this point is important because we will be working with the other
components of ELK later in the process.

Figure : Status Kibana

Once we got Elasticsearch working, we configured the visualization layer (Kibana) of the
ELK stack in the same way, we installed Kibana via the official Elastic repository. Then we
started by adding the official Elastic repository to our system, and we updated the package
index to be sure that we were working with the latest version. From there, we used the
package manager to successfully install Kibana.After the installation was complete, we
confirmed the service status by running sudo systemctl status kibana, which was helpful in
determining that kibana was running and active. Now that kibana is running, we can access it
via a web browser and use it to build dashboards, access log data, and see live system activity.
This is another critical step in providing a more engaging and user-friendly interface within
the SIEM platform, improving usability and effectiveness in general.

50 | P a g e
 Figure : Kibana interface
Reaching the Kibana interface at localhost :5601 marks a key milestone in our setup. From
here, we gain access to powerful nalytical capabilities to help us create custom dashboards,
create detection rules, and create alerts for our PKI environment. This interface will assist in
helping us to monitor events of importance in a timely manner and assess for potential
security concerns, including certificate abuse or OCSP-based attacks.

2. Threat Simulation : OCSP Relay and Malicious Activity

2.1. Attack Simulation : OCSP Relay and Certificate Forgery Attempt
In the context of PKI Tier 2 security testing, we conducted a simulated OCSP relay attack in a
controlled environment to demonstrate how the system can be used to abuse potential
certificate validation abuse. The test captured a valid OCSP response, then replayed the
response some time later in an effort to deceive the system into trusting a certificate, that had
already been revoked.
As an additional layer of complexity, we have also added a forged certificate claiming to be
from a trusted entity and a forged OCSP response. This situation is designed to see if the
system was able to verify attempts to to bypass validation using outdated or fraudulent
responses particularly in environments where nonce handling or timestamp verification might
be weak.
The figure below shows an OCSP relay attack where a MITM attacker alters the response to
make a revoked certificate appear valid.

51 | P a g e
 Figure : Diagram OCSP Relay scenario
In this attack, the MITM pretends to be a server and asks the OCSP responder about a target
certificate's revocation status. After the MITM receives a legitimate status revocation
response indicating that the certificate is revoked, it changes the response status to "good" and
forges a signature. The OCSP response is then sent to the client, who accepts the certificate as
valid.
The initial phase of simulating the OCSP relay attack was comprised of conducting network
enumeration to discover open ports on the target system. This made determining whether
there were any valid ports running the services listening for certificate validation requests
possible, while also allowing me to choose the port where the attacker will carry out its
interception and manipulation of OCSP traffic. This step is essential to placing the attacker in
between the client and the OCSP responder.

52 | P a g e
 Figure : Enumeration OCSP port
The enumeration results indicate that the target machine with the IP address of
192.168.10.134 has port 8888 opened and is hosting an unidentified service. This is an
opportunity for some exploitable weakness and a point to intercept and hijack a connection.
Since this is a simulation of an OCSP relay attack, This allows the attacker to intercept and
manipulate certificate status communications within the PKI infrastructure.

Figure : Captured Traffic

This command is shown OCSP relay attack simulation, and captures and forwards traffic to
port 8888, in which you had already identified as open during the enumeration phase. By
forwarding traffic through port 9999, the attacker is in the communication pathway for the
OCSP check and is essentially positioned as a man in the middle (MITM) attack.
This allows the attacker to observe, alter, or spoof OCSP responses, which is essential for
implemented the simulated forged certificate validation exploit.

Figure : Receiving Status of certif

Attacker successfully queries the OCSP Responder, and receives a response that confirms the
victim-PKI.crt certificate has been revoked. The response includes a keyCompromise
reason, and an exact revocation timestamp provides the attacker with real-time status
information to potentially falsify or replay in the next step of the OCSP relay attack.

Figure : MiTMproxy setup for OCSP Intercepiton

The attacker uses mitmproxy and pretends to be a fake OCSP responder on the PKI machine
(192.168.10.134) listening on port 8888. Incoming OCSP validation requests are intercepted,
53 | P a g e
passed to the backend (over port 9999 it is being served), and responses are modified via the
ocsp_relay.py script. Thus, the attacker is either responding as an OCSP responder with fake
OCSP responses or changing the revocation status of certificates, effectively completing the
man-in-the-middle attack chain and deceiving the client into trusting a revoked certificate.

Figure : OCSP_Relay Script

Mitmproxy will run the ocsp_relay.py script to intercept OCSP HTTP POST requests and
substitute the authentically received OCSP response with a fake response.

The proxy detects the header Content-Type : application/ocsp-request of the request, from
there it will inject a pre-defined, base64-encoded OCSP response with "good" certificate
status. The crafted response is decoded and used as the value of the intercepted flow, with the
correct Content-Type, and an HTTP status code of 200. This manipulation of the response
fulfills the conditions of the OCSP validation and has the intended effect of demonstrating a
situation in which a revoked certificate appears to have been successfully validated, and is a
fundamental illustration of the OCSP relay attack implementation.

Figure : Client OCSP Request Intercepted at Proxy

The attacker is able to successfully intercept the OCSP request when sent to 127.0.0.1:9999,
as a result he can capture the POST data containing a certificate validation query. This
provides the necessary the required input to later forge and inject an arbitrary OCSP response.

54 | P a g e
 Figure : Forged OCSP Response Injection
This phase represents the decisive moment in the attack at which the mitmproxy has
successfully intercepted an OCSP request and injected a false response. The log confirms two
important actions have occurred : the first is that the proxy has intercepted an OCSP request
from the client and the second is that a false OCSP response has been injected, indicating that
the OCSP response is “GOOD” It is established that the proxy has compromised certificate
validation through the use of a forged positive status for the potentially revoked certificate.
The attacker has effectively compromised the integrity of OCSP communication.

Figure : Display of Tampered OCSP Response Payload

This phase demonstrates sending a forged OCSP response to the client. The response is seen
as application/ocsp-response with a payload size of 1664 bytes The hex dump shows the
forged binary content that misrepresents the revocation status of the certificate as valid. This
gives the attacker the capability to bypass the certificate revocation mechanism, therefore
compromise the trust structure of the validation process.
Wireshark allows full visibility of a network, and captures all OCSP requests and responses
sent between the client and server. In this instance, the captured packets reveal a successful
OCSP communication. A forged response annotation was injected and indicated a certificate
subject status of "good (0)".

55 | P a g e
 Figure : Network Traffic Analysis of Forged OCSP Response

This comprehensive traffic assessment verifies the attack was successful, as it shows the
forged certificate status was accepted by the client and allowed revocation check to bypassed.
Wireshark's visibility is critical to both confirming the attack's execution and impact.

Figure : Forged OCSP Response Verified on PKI Host

This terminal output provides confirmation that the OCSP response verification was
successfully tested, from the machine that hosts the PKI infrastructure. Using the openssl ocsp
command, a validation request was sent to the OCSP Responder at
http://192.168.10.134:8888, and the manipulated response was accepted as legitimate.
The output indicates that the certificate status is ‘good’, thereby validating that the
manipulated response was accepted with validity verification, demonstrating the successful
man-in-the-middle OCSP attack in a controlled test.

56 | P a g e
 2.2. DDos attack :
We conducted a simulation of a Distributed Denial-of-Service (DDoS) attack targeting the
OCSP Responder within a Public Key Infrastructure (PKI) environment. This simulation
captures the interactions between three core entities : a malicious botnet attacker, the OCSP
Responder, and a legitimate client referred to as User1. Under normal operating conditions,
the OCSP Responder reliably processes certificate status requests and returns accurate
responses such as “GOOD” or “REVOKED” ensuring secure and uninterrupted certificate
validation.

Figure : DDos Attack Flow

During the simulated DDoS phase, a Bash script is deployed from the attacker machine (Kali
Linux) to continuously generate a high volume of OCSP requests targeting the responder at
192.168.10.134:8888.

Figure : Script DDos Attack

The script leverages a loop structure to repeatedly invoke the openssl ocsp command, using a
forged or legitimate certificate and suppressing output to /dev/null. Executed with high

57 | P a g e
frequency and parallelization, these requests consume critical system resources specifically
CPU and memory on the OCSP Responder.
This overload leads to delayed or failed responses to legitimate client requests, clearly
demonstrating the disruptive effects of DDoS attacks on certificate validation infrastructure
and underlining the need for robust mitigation measures such as rate-limiting, request
filtering, and dedicated security monitoring.

Figure : Error receiving response

The system has clearly been exhausted by DDoS script executions. CPU utilization is at a
constant 100%, which is fully saturated and unable to process further. Memory is 78%
utilized, and swap space has nearly been consumed (99.9%), indicating that the system is
dealing with memory pressure by writing data to disk.

Figure : System Overload

Moreover, the network graph reveals abnormal spikes in incoming and outgoing traffic, which
is typical of the flooding of OCSP requests associated with a denial-of-service scenario. With
all of these indicators at once, it can be concluded that the simulated attack is overwhelming
the system resources.

58 | P a g e
 2.3. SIEM Detection and monitoring
OCSP Relay Attack monitoring :
Following successfully simulating the OCSP relay attack, it is necessary to develop and
operate monitoring and detection capabilities within the SIEM platform, in this report the
ELK stack. We created a detection rule in Kibana to detect suspicious activity and provide
real-time visibility. The detection rule we created will identify anomalous events in the
ocsp10-logs data view. The relevant detection is when the certificate status from the OCSP
changes from "revoked" to "good" for a known client IP (192.168.10.134).

Figure : Custom Detection Rule for OCSP Replay Attack

The rule is configured to send an alert any time a single OCSP event meets the configured
thresholds in a single five-minute window, reflecting a very high degree of sensitivity to early
detection of malicious certificate status manipulation. By continuously monitoring log data
however far back in time the user selects, the rule allows real-time analysis of data and helps
to proactively monitor for possible OCSP relay attacks.

59 | P a g e
 Figure : Rule Deployment for OCSP Attack Detection

Once deployed, it automatically monitors incoming traffic to detect any attempts to

manipulate the service—such as changes of status from “revoked” to “good”—an alert would
be triggered immediately upon the detection of this behavior. This approach significantly
strengthens in reinforcing the detection and response capability of the SIEM, empowering
security teams to recognize and respond to threats quickly, and protecting the integrity of the
digital certificate validation process.
Using Filebeat, logs are forwarded to Kibana, facilitating centralized collection and analysis
of OCSP events. With this setup, analysts can observe and correlate events by their
timestamps, as demonstrated in the image below, helping to clarify the sequence and timing
of the forged certificate responses.

Figure : Visualization of OCSP Relay Attack Events

The visualized logs in Kibana verify that OCSP relay attack activity has been successfully
detected and tracked through the ELK stack. The dashboard displays a series of log messages
showing that that forged OCSP responses were accepted, the status of certificates were
illegitimately altered from revoked to good, and the revocation check was bypassed through a
replayed response. These detailed event records events were gathered and parsed from the
designated data view, providing real-time insight into malicious OCSP traffic.

60 | P a g e
 Figure : OCSP Relay Attack Rule Execution Log

Concurrently, the alerting engine verifies that the detection rule is appropriately defined and
running at appropriate frequencies. The production of reliable alerts, hitting these pre-
determined thresholds, verifies that it successfully detecting suspicious activity matching the
characteristics of the simulated OCSP relay attack. Indicating the depth of the SIEM
configuration to monitor certificate validation behavior, allowing information security teams
to quickly detect, investigate, and respond, to malicious attempts that would bypass traditional
revocation checks.

Figure : OCSP Status Distribution

Figure : Dashboard OCSP Relay Attack

61 | P a g e
As a concluding phase of the OCSP Relay attack monitoring project, a deliberate Kibana
dashboard was created to assist in the clear and actionable representation of collected alerts
within the monitoring data. The dashboard showed two relevant visualizations bar chart
depicting OCSP alerts per IP, and a pie chart to summarize the OCSP alerts listed by message
status (good, revoked, unknown). The monitoring dashboard allows users to quickly identify
the IP addresses generating the most OCSP-related traffic and focused visualizations for the
IP 192.168.10.134, in the third visualisation dentified during the investigation.

DDos Attack monitoring :

To observe and potentially detect Distributed Denial of Service (DDoS) attacks, we rely on
real-time system performance metrics and OCSP log analysis using the ELK Stack. DDoS
activity is typically characterized by high CPU usage, memory saturation, and spikes in
network traffic.

Figure : CPU / Memory usage

The dashboard above displays key performance measurements while the suspected DDoS
attack occurred. The area chart on the left shows a major spike in CPU system and user
activity and CPU utilization spiking above 90%. The gauge panels on the right confirm a
sustained high CPU load (91%) and memory usage (94%), which are strong indicators of
resource exhaustion seen during DDoS behaviors. These metrics support the hypothesis of a
system under stress due to excessive request volume, validating the need for further threat
analysis and mitigation.

62 | P a g e
Conclusoin :

In this chapter, we have shown an implementation of a modular two-tier PKI that runs on a
Debian-based Linux distribution using OpenSSL, Apache2, and OCSP for certificate
management and validation. We demonstrated real-world examples including the use of
certificates for HTTPS and successful OCSP stapling, as well as simulated DDoS attacks
against the OCSP responder that confirmed the robustness of the system whilst also
highlighting prominent areas for hardening. Overall, the results highlight the importance of
continuous monitoring and proactive threat detection in maintaining PKI integrity.

63 | P a g e
Chapitre4 : Enterprise PKI Infrastructure on Windows (Active Directory Certificate Services):

64 | P a g e
Introduction :
This chapter outlines the establishment of a PKI, with Microsoft’s Active Directory
Certificate Services (AD CS) as the implementation in a Tier 2 enterprise organization. It will
covers the secure design and deployment of a certificate authority (CA) hierarchy with an
offline root CA, an online intermediary CA and the integration of an Online Certificate Status
Protocol (OCSP) responder for real-time certificate status checking.
It also addresses security by simulating potential certificate based attacks (ESC1 and ESC7)
and forwarding those logs to Winlogbeat, and using an ELK-based SIEM to see anomolies,
with the intent of creating a working PKI as well as a monitored and secure system.

Part 1 : Designing and Implementing a Tier 2 AD CS PKI Infrastructure

1. Enterprise PKI Architecture and Role Allocation :

Figure : Tier 2 PKI Architecture

The Tier 2 Active Directory Certificate Services (AD CS) infrastructure is designed using a
hierarchical Public Key Infrastructure (PKI) model to provide an appropriate level of security,
separation and resiliency. The infrastructure consists of the following key components :

 Offline Root Certification Authority (Root CA) :

This is the trust anchor of the PKI. It is completely air-gapped, and only brought online to
sign and issue the Intermediate CA's certificate and to publish CRLs. The Root CA is not
domain-joined in order to reduce its attack surface, and is configured with long validity and
strict issuance policies.
65 | P a g e
  Online Intermediate Certification Authority (Issuing CA) :
The Intermediate CA is a domain-joined component for daily certificate issuance, renewal,
and revocation. It has the only direct interaction with clients and Active Directory. Its
configuration enforces policy restrictions as defined by the Root CA and it goes with the
OCSP responder for certificate validation.

 OCSP Responder :
The Online Certificate Status Protocol (OCSP) responder allows instantaneous real-time
certificate status checking. It is more efficient than CRLs and removes the need for obtaining
and downloading full CRLs. It is also tightly integrated with the Intermediate CA, and it
makes the certificate revocation status available to the relying parties and applications.

 Tier 2 Active Directory (AD) Clients :

These systems are domain-joined systems that request and enroll certificates from the
Intermediate CA. If templates are misconfigured or the permissions associated with
enrollment are weakly configured, then these endpoints could be at risk for attacks, such as
ESC1/ ESC7/Ntlm attacks, in which a low-privileged user could escalate their privileges to
system or domain admin by exploiting certificate templates.

 Winlogbeat Agents and ELK SIEM Stack :

Events related to PKI need to be monitored and visible therefore logs are forwarded from
clients and servers to an ELK-based SIEM platform using Winlogbeat. This allows
detection of anomalies and attack simulations, especially where a certificate has been abused
or an unauthorized attempt to access a sensitive resources.
1.1. Active Directory Domain Setup and Configuration :
In order to implement a Tier 2 AD CS (Active Directory Certificate Services) Public Key
Infrastructure, a centralized Active Directory domain must first be established. A dedicated
domain must be created which will serve as the trusted identity platform for all PKI-related
services. The Root Certification Authority (Root CA) and Subordinate Certification Authority
(SubCA) must both be in this same domain to ensure certificate chaining, policy enforcement,
and enforcement of access control.

66 | P a g e
Placing both CAs within the same domain facilitates secure communications, simplifies
Group Policy deployment, and supports streamlined management of CA permissions and
certificate templates.

Figure : Download the AD-DS

The sequence illustrates how to install the Active Directory Domain Services (AD DS) role
on the RootCA server. The installation procedure starts with the type of installation (role-
based) and picking the server from the server pool. The next action is to choose the AD DS
role so the server can be a domain controller. When the installation is complete, the system
prompts for post-installation configuration to elevate the server to a domain controller and
establish the basic domain environment for the integration and management of the Tier 2 PKI
infrastructure.

Figure : Configuration AD-DS

The configuration steps continue on by building a new forest with the domain name,
marocdxcpki.local, which will be the domain for the PKI environment and the central

67 | P a g e
directory service. The forest and domain functional levels were changed to Windows Server
2016 to allow for modern capabilities. The DNS role and Global Catalog role were also
configured enabled for name resolution and directory search, and a Directory Services Restore
Mode (DSRM) password was defined to allow recovery options.

Figure : Domain Functionality Verification

Server Manager has confirmed the successful domain configuration and the RootCA server
has now joined the new domain marocdxcpki.local. The RootCA server is now a domain
controller and is ready to be used to complete additional tasks to deploy the rest of the PKI
infrastructure tasks.

1.2. Offline Root Certification Authority : Installation and Hardening

To begin configuring the Offline Root CA, the Active Directory Certificate Services (AD CS)
role was installed on the RootCA server. During the process of installing the role, the
authority Certification Authority, this service was selected to issue and manage digital
certificates.

68 | P a g e
 Figure : Root CA Role Service Selection

This step will be critical to ensuring that the Root CA has the ability to be the trusted anchor
in the PKI forest, along with verifying certificates and providing a chain of trust.
The "Certification Authority" role service is chosen to configure the Root CA for issuing and
managing certificates.

Figure : Configuration RootCA (1/6)

Figure : Configuration RootCA (2/7)

Choosing the « Standalone CA » option indicates that the Root CA operates autonomously,
without requiring Active Directory integration, where certificate issuance is tightly controlled

69 | P a g e
and infrequent Typically, Root CAs operate in a standalone mode to guarantee maximum
security and isolation.

Figure : Configuration RootCA (3/7)

"Root CA" is chosen for the authority types, this will place this server at the top of the
certificate chain of trust. It will generate its own certificate signed by itself, this becomes the
root of trust for all subordinate CAs.

Figure : Configuration RootCA (4/7)

A descriptive common name, marocdxcpki-ROOTCA-CA, has been assigned so the Root

CA can be easily identified within the certificate chains. The distinguished name was created

70 | P a g e
to also automatically derived from the domain structure to ensure consistent recognition
across logs, issued certificates, and client trust stores.

Figure : Configuration RootCA (5/7)

The final configuration gives a summary of all selected parameters, including the CA type,
cryptographic provider, key length, and period of certificate validity. It confirms the use of
SHA256 for the hashing algorithm with a 2048-bit RSA key, and the certificate will be valid
for five years, allowing one final review of the settings.

Figure : Configuration RootCA (6/7)

71 | P a g e
The configuration of AD CS is finished successfully, this indicates that the role Certification
Authority was installed and initialized correctly. The RootCA is now ready to work as a
trusted root node of the PKI hierarchy.

Figure : Configuration RootCA (7/7)

In the Certification Authority console, we can see the offline Root CA (marocdxcpki-
ROOTCA-CA), which shows that it is correctly installed and working. This CA is an offline
CA and is only used to sign subordinate CA certificates and publish CRLs.

1.3. Intermediate CA Deployment and Certificate Policy Enforcement :

The installation of the Web Enrollment role service has been completed, and the next step is
to configure the Subordinate Certification Authority (SubCA). This will also require
certificate request generation on the SubCA and then transmitting the request, in a secure
manner, to the offline RootCA for signing. When the RootCA signs the request and issues the
subordinate certificate, it will be imported back into the SubCA to complete the trust chain,
and provide a fully functioning two-tier PKI hierarchy.

72 | P a g e
 Figure : Configuration SubCA (1/6)

The SubCA is configured with the Certification Authority and Web Enrollment role services.
The Web Enrollment role service provides certificate requests via a web-based interface to
facilitate client access. This configuration provides an overall way to distribute user and
device certificates in enterprise environments.

Figure : Configuration SubCA (2/6)

The selected setup type is Enterprise CA, which means that the CA is also integrated with
Active Directory, and allows for automatic certificate enrollment and policy application
across domain-joined devices. Since we are setting up a SubCA, it must always be online and
accessible to the domain.

73 | P a g e
 Figure : Configuration SubCA (3/6)

The selected CA type is a Subordinate CA which depends on the parent CA for its signing
certificate and does not create a self-signed root certificate, but builds trust from the RootCA,
enforcing a hierarchical trust model in the PKI architecture.

Figure : Configuration SubCA (4/6)

The common name marocdxcpki-SUBCA-CA has been assigned to easily identify the
Subordinate CA and is automatically concatenated with the domain to form the full
distinguished name (DN) so that we can clearly identify and validate any certificates issued
by the CA.

74 | P a g e
 Figure : Configuration SubCA (5/6)

The SubCA creates a certificate request file locally and the administrator must be manually
transferred to the RootCA for signing, which is an essential part of establishing the trust chain
in the PKI hierarchy and completing the setup of the SubCA.

Figure : Configuration SubCA (6/6)

The last summary identifies the chosen configuration settings that include cryptographic
parameters (SHA256, 2048-bit RSA key) and file paths as verification that the SubCA is
ready to operate under the authority of the RootCA, completing the configuration stage before
issuing the certificate.

75 | P a g e
After the certificate request for the SubCA is generated, it is manually exported and submitted
to the RootCA for signing. This request will appear as a Pending Request in the Certification
Authority console on the RootCA, showing it has been received and is awaiting approval.
This step is an important authentication review before issuing a subordinate certificate, which
establishes the trust hierarchy.

Figure : IssuingSubCA

When the request is reviewed and approved by the RootCA administrator, it will be signed,
and moved to issued certificates. The subordinate certificate must then be exported and
returned to the SubCA. Now the SubCA can complete the certificate chain and issue trusted
certificates in the PKI environment.

1.4. OCSP Responder : Configuration and Certificate Status Integration

The Online Certificate Status Protocol (OCSP) Responder is an important part of a Public
Key Infrastructure (PKI) as it provides real-time verification of a certificate revocation status.
OCSP uses a simple, quick and light protocol instead of downloading full Certificate
Revocation Lists to check if certificates are revoked. This enhances performance, and is
especially important in the case of high security and high availability environments where it is
essential to determine the validity of a certificate.

76 | P a g e
 Figure : OCSP Role Service Installation

In this phase, we only selected the Online Responder role service. With this configuration, we
are isolating OCSP functionality into its own module from the Certification Authority role
service, thereby improving modularity and security across the overall PKI architecture.

Figure : Online Responder

Role Configuration

The configuration wizard indicates only the Online Responder will be configured, and there
won't be any additional services on this OCSP-dedicated server, confirming that it will be
serving a single purpose of responding to certificate status requests.

Figure : Successful Installation of the Online Responder Role

The Online Responder is now properly installed and prepared to process real-time certificate
validity checks to facilitate revocation verification, without relying on full CRL downloads,
enhancing secure, responsive certificate-based authentication.

77 | P a g e
 Figure : SubCA AIA and OCSP URL Configuration

The Authority Information Access (AIA) and OCSP extension settings are located under the
SubCA properties. The OCSP URL (http://OCSPServ.marocdxcpki.local/ocsp) is provided
so that the issued certificates contain a point to the responder, so clients can find and contact
the OCSP server for verification.

Figure : Associating the Online Responder with the Subordinate CA

78 | P a g e
The Online Responder has been configured and is now connected to the Subordinate CA
marocdxcpki-SUBCA-CA and can now respond to requests for real time revocation status of
requested certificates with the OCSP validation fully functional across the PKI Environment.

Part 2 : Threat Simulation and Detection in AD CS Infrastructure

1. Security Testing and Attack Simulation on AD CS Infrastructure :

1.1. ESC1 Attack simultion :

The ESC1 (Enterprise Security Control 1) attack targets the variables found in Active
Directory Certificate Services (AD CS), and specifically when Certificate Templates are
misconfigured to allow low privileged users to request certificates for arbitrary subjects,
including high-privileged accounts like domain admins. This is when certain Certificate
Templates are misconfigured to allow users to have ENROLLEE_SUPPLIES_SUBJECT,
and no access control was configured. Attackers can request a certificate to impersonate a
privileged user.

79 | P a g e
 Figure : ESC1 Attack Flow
The proccess begins with enumeration as the first step in simulating the attack, Certify.exe is
used by the attacker to list ceritficate templates on the CA, SubCA.marocdxcpki.local\
marocdxcpki.local-SubCA-CA, where VulnTemplate is found to be misconfigured. The
vulnerability in this template arises from its abulity to let users define any subject, even
privileged accounts, using the ENROLLEE_SUPPLIES_SUBJECT flag.

Figure : Discovery of Vulnerable Template

80 | P a g e
After identification of the vulnerable certificate template through enumeration, the attacker
proceeds to exploit the vulnerability. The attacker requests a certificate, using the vulnerable
VulnTemplate and impersonating a privileged user localadmin.

Figure : Malicious Certificate Request as ‘localadmin’

The attacker use Certify.exe to create a certificate request to the CA, SubCA.marocdxcpki.
local, including localadmin as the AltName. Despite the request being completed with the
low-privileged user pki, the CA issues the certificate without verifying the subject. The
resulting certificate, which was saved as cert.pem, is cryptographically associated with the
spoofed identity and will be used in the next stage to authenticate using Kerberos to escalate
privileges.

The attacker executes Rubeus.exe to create a Kerberos Ticket Granting Ticket (TGT) through
the PKINIT process, which allows the attacker to authenticate as the impersonated local
admin user without entering their password.

81 | P a g e
 Figure : Kerberos TGT Request via Malicious Certificate

In Rubeus.exe, the attacker executes the asktgt module with the .pfx certificate file generated
during the previouse phase, using the certification and its password, he have the right to
manages to request and secure a Kerberos TGT for the user marocdxcpki. Local\
localadmin. The retieved TGT indicates that the attacker has successfully impersonated a
high-privilege domain user, allowing access to critical resources across the network.

Figure : TGT Imported and Privileged Access Confirmed

82 | P a g e
In the final phase of the attack, the adversary is importing the Kerberos Ticket Granting
Ticket (TGT) they previously collected into their session using Rubeus.The output indicates
that the ticket is valid and is associated with the impersonated high-privilege user localadmin.
With this ticket issued, the attacker was able to successfully interact with the administrative
share\\SubCA.marocdxcpki.local\C$, which had been previously limited. This confirms that
the privilege escalation was successful and therefore the attacker had unrestricted access to
the target server's file system which is a clear demonstration of post-exploitation ability after
exploiting certificate-based authentication.

1.2 ESC7 Attack simultion :

ESC7 is a privilege escalation attack that uses a certificate-based template that requires
manager approval. In this case, a low-privileged user makes a certificate request with the
vulnerable "ApprovalNeeded" template, and since the same user or a compromised account
has approval rights to approve pending requests, the certificate will be issued with no
separation of duties. Once a low-privileged user obtains the certificate, they can authenticate
with PKINIT to impersonate privileged users, which means they have fully compromised the
domain without needing credentials.

Figure : ESC7 Attack Flow

After having established context and mechanics around the ESC7 attack, we can now move
forward with the hands-on EMSE. The intent of this demonstration is to show how a user with
limited permissions who has been given the ability to enroll and approve can exploit a

83 | P a g e
misconfigured certificate template to elevate access credentials. I will execute the process in a
series of steps : request the certificate, approve the request, obtain the approved and issued
certificate, and finally use it to impersonate a high privileged account to compromise security
boundaries.

Figure : Enumerating Certificate Authority Permissions

In this PowerShell output, we can see the use of Get-CertificationAuthorityAcl to enumerate

the access control list (ACL) of a Certificate Authority hosted on SubCA.marocdxcpki.
local. We observe that the user MAROCDXCPKI\certmanager has both
ManageCertificates and Enroll rights. This is critical because, in an ESC7 attack, a user needs
the ability to both request and approve certificates. That these rights exist indicates that the
certmanager account can approve its own requests for certificates, which is the central
misconfiguration that ESC7 seeks to exploit.

84 | P a g e
 Figure : Inspecting and Modifying CA Configuration with PSPKI Module

The attacker uses the PowerShell PSPKI module to interact with the CA configuration files.
We create a $ConfigReader object for SubCA.marocdxcpki.local, set the root context, and
then read the existing value for the EditFlags registry entry in the policy module.This registry
entry defines how templates are processed. Finally, the attacker sets a new value (1376590)
and including the flags like EDITF_UNSUBJECTALTNAME2. Those flags will let the
attacker add Subject Alternative Names (SAN), or attempt to escalate, by modifying
certificate fields in further steps.

Figure : Verifying EditFlags Before and After Modification

We uses certutil -getreg to check the registry values of the CA policy module’s EditFlags
before and after modification. The value of the EditFlags registry value initially is 1110446
and after modification, it is 1376590, confirming the new setting is applied successfully. This
new flag allows additional new features such as custom certificate attributes also meaning that
the CA is allowing even more freely flexible and potentially risky request customizations.
85 | P a g e
 Figure : Crafting and Submitting a Malicious Certificate Request

The attacker leverages the Certify tool to submit a certificate request to the CA at
SubCA.marocdxcpki.local\marocdxcpki-SUBCA-CA, using the ApprovalNeeded
template. The certmanager account has privileges to both enroll and approve an enrollment
request, it means that the certificate request may not need any outside validation, the
certificate is still pending status, but the private key is generated and shown. This step is
important because it will allow the attacker to later impersonate privileged users or lateral
move through Kerberos authentication.

Figure : Approving the Certificate Request with PSPKI

The Approve-CertificateRequest cmdlet is used to approve the certificate request that had
previously been submitted (ID 14), we can see from PowerShell output that the certificate has
also been issued.

86 | P a g e
Here we can see the critical misconfiguration that ESC7 is based on. The account that has
both enrollment and approve permissions is able to carry out its own request for a certificate
and entirely bypass security controls and approval workflows.

Figure : Downloading the Issued Certificate with Certify

In the last step, the certificate identified by request ID 14 is retrieved using the Certify tool
and the command download, which allows the user to retrieve the certificate in a complete
state and its matching private key. With the complete certificate and the private key available
to the user, he can then use the certificate to authenticate as the identity defined within it such
as domain administrator based on the permissions contained in the certificate template.

2. Event Forwarding, Logging, and SIEM Monitoring (Winlogbeat / ELK)

2.1. Log Collection and Forwarding :

To ensure monitoring of the Active Directory Certificate Services (AD CS) infrastructure, and
to potentially alert on advanced certificate-based attacks ESC1 and ESC7, a centralized
logging and monitoring environment was possible with the use of Winlogbeat. The agent was
installed as a service on three machines, which are important for this simulation : the Domain
Controller, Subordinate Certification Authority (SubCA), SubCA.marocdxcpki.local, and
the client machine to perform the malicious action.

87 | P a g e
The winlogbeat.yml configuration has tracked logs from three important sources : Security,
System, and Microsoft-Windows-CertificationAuthority/Operational. This has given good
visibility into key actions such as permission changes, certificate issuance, and Kerberos
authentication flows.

Figure : winlogbeat.yml file

Specifically, the setup targeted event IDs 4670 (object permission changes), 4886 (certificate
request submission), 4887 (certificate issuance), and 4768 (Kerberos Ticket Granting Ticket
requests via PKINIT), all critical for correlating privilege escalation and lateral movement
attempts. Logs were forwarded directly to Elasticsearch without using Logstash and were
indexed under a dedicated data view called winlogs. This enabled real-time querying in
Kibana’s Discover panel, the development of tailored SIEM detection rules, and the creation
of interactive dashboards to visualize and track the simulated attacks.

2.2. Detection Rules Implementation :

To actively track privilege escalation activity in the style of ESC1 and ESC7 registrations in
an Active Directory Certificate Services (AD CS) environment, we created and deployed
custom detection rules in the SIEM module in Kibana using Elastic Security, specifically to
identify unauthorized actions that abuse misconfigured certificate services to include the use
of sensitive template permissions and certificate request approvals.

88 | P a g e
The ESC1 detection rule tracks events categorized as “ESC1 attack detected” in the winlogs
data view. It is built to record changes to certificate template permissions (especially via
administrative shares like C$) and flags behavior from accounts like localadmin and other
non-standard principals. This detection rule looks for the latest findings to correlate these
changes with a later authentication event, like a successful Kerberos TGT (in order to track
Golden Certificate-Style abuse).

Figure : ESC1 Detection Rule Configuration

To identify scenarios of users submitting and approving their own certificate request ESC7, a
rule was created to monitor the use of templates that allow both enrollment and approval
permissions on the same template. This rule is able to correlate logs using certificate.
Request_id, user.name, and client.ip, the rule is able to identify events where a single user
bypasses the approval workflow, an action that demonstrates a possible privilege escalation.

Figure : ESC7 Detection Rule Configuration

89 | P a g e
 2.3 Log Visualization : Kibana Discover View

To validate detection rules and analyze the attack sequence, Kibana’s Discover view was used
to inspect real-time logs from the Subordinate CA (SubCA.marocdxcpki.local). Using the
winlogs data view, key fields like event codes, usernames, and sources were filtered to reveal
critical ESC1 stages, including unauthorized template changes and certificate requests.

Figure : ESC1 Attack Log Entries in Kibana Discover View

As detailed in the Discover interface, the timeline and logs indicate where the events
associated with the simulated attack occurred. Each log entry is timestamped, indexed, and
contains fields such as event.code, event.provider, and host.name, allowing for correlation
of details. This information demonstrates not only successful detection but also underlines the
efficacy of centralized logging and field-specific filtering to monitor and analyze attempts at
privilege escalation by certificates.

90 | P a g e
 Figure : ESC7 Attack Log Entries in Kibana Discover View

To track the ESC7 attack sequence, logs were examined in Kibana’s Discover view under the
winlogs data view. The records show a user (certmanager) submitting and self-approving a
certificate request, followed by the issuance of a Kerberos Ticket Granting Ticket (TGT) via
PKINIT. The correlation of event fields such as event.code, host.name, user.name, and
source.ip provided clear indicators of privilege escalation activity. This visual confirmation
supports the detection rule’s effectiveness in identifying ESC7 exploitation scenarios.

2.4 Dashboards and Correlation View

To gain visibility into the sequence, frequency, and attributes of ESC1 and ESC7 attack
events, a custom Kibana dashboard was created. The dashboard uses the winlogs data view
and groups logs together using key fields like event.code, event.provider, user.name, and
@timestamp. These visualizations provide an overview of the overall malicious activity
patterns, such as which event sources were triggered, which users engaged in the suspicious
activity, and when these activities occurred.

Figure : Dashboard ESC1/7 perUser by Timestamp

91 | P a g e
This dual-panel visualization offers valuable insight into the distribution and timing of ESC1
and ESC7 attack events. On the left, the donut chart titled “ESC1 vs ESC7 per User”
highlights user involvement, showing that certmanager was responsible for 59.18% of the
activity primarily associated with ESC7 while localadmin accounted for 40.82%, linked to
ESC1. On the right, the time series bar chart illustrates the frequency of these attacks over
time, with a noticeable spike in events occurring during a specific 30-minute window.

Figure : Event Code Distribution by Event Provider

This visualization, titled "EventID/EventProvider", presents a time-based correlation of event

codes generated by various Microsoft-Windows event providers during the ESC1 and ESC7
attack simulations. The graph displays the median values of event.code plotted against
precise timestamps (per minute), offering a clear temporal view of when critical events such
as template modifications and certificate issuance occurred.

This visualization, titled "EventID/EventProvider", displays a time-based correlation of

event codes generated by various Microsoft-Windows event providers during the ESC1 and
ESC7 attack simulations. It charts the median values of Event.code, offering a clear temporal
breakdown of critical actions such as template modifications and certificate-based
authentications. Groupings of events over short intervals reveal periods of high activity,
enabling analysts to trace suspicious behavior to specific providers and enhance both forensic
investigation and real-time monitoring efforts.

92 | P a g e
Conclusion :

This chapter demonstrated the implementation of a secure, tiered PKI using Microsoft AD
CS, featuring an offline Root CA, an online Subordinate CA, and an integrated OCSP
responder for real-time certificate validation. By simulating certificate-based attacks such as
ESC1 and ESC7 and forwarding event logs to an ELK-based SIEM via Winlogbeat, the
project showcased how PKI can be both operationally effective and security-aware. The
resulting infrastructure not only supports strong identity assurance but also enables real-time
detection and response to certificate misuse, reinforcing the importance of monitoring in
modern PKI environments.

93 | P a g e
Chapittre5 : System Assessment and Improvement Strategies

94 | P a g e
Introduction :

The chapter provides a comparative analysis and evaluation of two implementations of Public
Key Infrastructure (PKI) on an enterprise basis : Linux OpenSSL and Windows Active
Directory Certificate Services (AD CS). The goal is to demonstrate how these approaches
operate to highlight their differences, strengths, and weaknesses when actually used in
enterprise operational environments. Through structured evaluation criteria such as
automation, integration, scalability, security, and administrative efficiency, this chapter
provides insights into performance outcomes, security observations, and deployment
challenges. Based on these findings, best practices and strategic recommendations are offered
to guide future PKI implementations, particularly in hybrid or large-scale infrastructures.

1. Comparative Analysis : Linux OpenSSL vs. Windows AD CS

Evaluation Criteria Linux OpenSSL Windows AD CS

Platform Cross-platform (Linux, Windows Server only
Unix, Windows)
AD Integration Manual LDAP/Samba Native AD integration
setup
Interface CLI (openssl, scripts) GUI , PowerShell
Automation Bash, Python, Ansible GPO, PowerShell,
Templates
Enrollment Manual/scripts or APIs Auto-enrollment via AD
OCSP/CRL Manual OCSP/CRL Built-in OCSP/CRL
config support
Policy Control Basic via openssl.cnf Templates with fine
control
Logging Syslog/journald, third- Event Viewer,
party tools Winlogbeat, ELK
Scalability Custom replication setup Built-in multi-tier support
Security Customizable, admin- Hardened with ACLs,
driven RBAC
Learning Curve High: deep PKI Moderate: guided
knowledge needed tools/docs
Support Community-based Microsoft enterprise
support support

Table : Comparative Evaluation Linux vs AD CS

95 | P a g e
The table above shows the similarities and differences between Linux OpenSSL and
Windows AD CS. The strengths of Linux OpenSSL can be summarized as flexibility, cross-
platform, and customization. Linux OpenSSL is particularly suited to highly specialized or
non-Windows environments. However, it requires significant administrative expertise and
manual configuration. In contrast, Windows AD CS provides seamless integration with
Active Directory, built-in automation, and user-friendly interfaces, making it the preferred
solution for enterprises operating within Microsoft ecosystems. The evaluation underscores
the trade-off between flexibility and ease of deployment, serving as a foundation for selecting
the appropriate PKI solution based on organizational needs and technical experts.

2.Impact Assessment of PKI-Specific Attacks on Security Properties

Attack Type Confidentiality Integrity Availability

OCSP Relay ✔Expose ❌ ✔Disrupt trust
Attack certificate status validation by relaying
queries, enabling outdated or
profiling. manipulated responses.
DDoS Attack on ❌ ❌ ✔Directly affects
OCSP Responder availability by flooding
OCSP responders,
making services
unreachable.
ESC1 (Template ✔Allows privilege ✔Abuse of ❌
Misconfiguration escalation, possibly certificate issuance
- Enrollment exposing sensitive compromises trust
Agent) systems and user chain integrity.
credentials.
ESC7 (Weak ✔Low-privileged ✔Breaks CA ❌
Enrollment users can request policy and trust
Permissions) high-privileged boundaries.
certificates, leading
to lateral
movement.

Table : Impact per Attack

This assessment describes the security impact of important PKI attack vectors on the CIA
model. OCSP Relay attacks and DoS attacks primarily impact availability through impacts to
certificate validation services. Misconfigurations including ESC1 and ESC7 have critical
security implications compromising confidentiality and integrity measures via unauthorized
privilege escalation and by-passing policy compliance. These review findings underscore the
importance of having strict template permissions, monitoring OCSP services, and establishing

96 | P a g e
proactive discovery/regulatory mechanisms for the integrity of enterprise certificate
infrastructures.

3. Mitigation Strategies for PKI-Based Attacks

3.1. OCSP Relay Attack :

OCSP must staple The OCSP Must-Staple extension improves revocation enforcement in that
it requires a valid stapled OCSP response be presented during the TLS handshake. Thus,
clients cannot avoid revocation checking or rely on stale status information about the
certificate. In addition, the ocsp-staple extension ensures real time checking or validation,
which protects clients from the potential of an attack, such as a man-in-the-middle (MitM)
attack, taking advantage of absence of a status check. An OCSP Must-Staple response is an
important tool in environments where strict certificate trust benefits are required.

Figure : OCSP Must-Staple

Implementing TLS 1.2 and 1.3 is important for making PKI communications safe. Both
protocols provide strong encryption, and forward secrecy, as well as being resilient to the
attacks of previous generations of cryptography. TLS 1.3 improves performance and
maintains modern security by removing legacy negotiation settings. When TLS 1.2 or 1.3 is
combined with OCSP Stapling and Must-Staple, they enable secure and trusted certificate
validation ecosystems.

97 | P a g e
 3.2. DDOS Attack :

The primary objective of this design is for the OCSP service to provide high availability, fault
tolerance and resilient delivery. This intent is accomplished by distributing client requests
across multiple responder instances. The infrastructure remains available to respond to client
requests in periods of overwhelming loads or in cases where an individual component may
fail.

 Deploy Multiple OCSP Responder : OCSP Responders should be deployed on

separate servers, to distribute incoming OCSP requests. Its ideal to ensure availability
improve fault tolerance and reduces risk of simultaneous failure.
 Reverse Proxy Shielding : To increase security, configure mod_authz_host in
Apache2 to allow access only to acceptable ranges of IPs. Since Apache2 is also a
reverse proxy, it acts like a protective checkpoint that can filter, throttle, and control
incoming traffic, which can decrease the impact of a DoS attack and block requests
that are unauthorized before it reaches the OCSP responders.

Figure : PKI DDoS-Resilient Architecture

98 | P a g e
This architecture represents a safe and secure PKI deployment intended to address denial-of-
service (DoS) and OCSP replay attacks. The architecture includes a reverse proxy (Apache2)
serving in front of the two OCSP responders to filter traffic, load balancing, and isolate
critical services. The two OCSP responders provide redundancy, fault tolerance, and
availability. Remotely separating the subordinate CA and the Offline root CA maintains the
integrity of the trust chain. Following this modular layered approach is a best practice of
security posture for PKI that can offer availability and scalability of message integrity and
real-time certificate validation protection.

3.3. ESC1 Enrollment Agent Template Abuse

Harden or Decommission Enrollment Agent Templates : ESC1 stems from overly

permissive Enrollment Agent certificate templates, which empower a user to request
certificates for other identities. Unless these templates are strictly controlled, attackers can
abuse them to gain elevated privileges. The safest approach is to disable the templates entirely
or permit them only for a very limited set of highly trusted, administrative accounts. Where
business needs demand their use, place them behind a manual approval workflow so each
issuance must be explicitly authorized.

Lock Down Template : Access Apply fine grained ACLs on each Enrollment Agent template
so only designated administrators can read or enroll the template. This granular control blocks
unauthorized users from viewing or invoking the template.

Attribute Secure Configuration Rationale

msPKI-Enrollment-Flag Set to 0 (None) or require Prevents automatic
CA-manager approval issuance and forces a
second set of eyes on
sensitive requests
Authorized Signatures Enabled Demands a co-sign or
Required manager sign-off before
the certificate is issued
PKI-Extended-Key-Usag Restrict to essential EKUs Eliminates unnecessary
e only key usages that attackers
could leverage
Enrollment Permissions Grant only to specific Removes blanket access
security groups; never that can lead to privilege
“Everyone” or escalation
“Authenticated Users”

Table : ESC1 Hardening Guide

99 | P a g e
 3.4. ESC7 Misconfigured Enrollment Permissions

To protect organizations against ESC7, they should restrict enrollment permissions on

sensitive certificate templates from broad groups such as “Authenticated Users” or “Domain
Users”. Enrollment permissions should only be granted to well- defined, minimal user groups,
based on least privilege. Additionally, separate certificate templates should be created for
high-privilege accounts (domain admins), each with stricter security settings. Regular audits
and periodic reviews of all certificate templates are essential to ensure no unintentional
exposure. Organizations should also configure custom detection rules in their SIEM platforms
to alert on unusual or unauthorized certificate requests especially from accounts not typically
using those templates.
4.Future Improvements
While this project successfully demonstrated the design, deployment, and security of a Tier 2
PKI infrastructure using Active Directory Certificate Services (AD CS). However, there are
many enhancements that can be applied in future iterations to improve scalability, automation,
and resilience :

 Integration with Hardware Security Modules (HSMs) :

Future deployments should also make use of HSMs, or vHSMs, to provide stronger
protection for private keys, especially for Root and Issuing CAs. HSMs strengthen
security around cryptographic key storage, can help fulfill FIPS 140-2 compliance, and
reduce threats and risk from key theft or software-based key compromise.

Figure : HSMs use cases

100 | P a g e
  Advanced SIEM Integration and Threat Modeling with SOAR :
For future enhancement, combining a SOAR platform with an ELK-based SIEM can
automate responses - such as certificate revocation or account lockdown - when a threat
like ESC1/7 or OCSP misuse occurs. In addition, the PKI infrastructure can be further
expanded to support VPN authentication, or integrated into a Zero Trust Network
Model, which could enable strong access control for all services using certificate-based
access control. This will lead to improved incident response speed and system resilience
overall. If we add continuous policy audits and template management, the PKI can be
adapted into a fully adaptive trust framework.

Figure : Key Pillars of SOAR

 Zero Trust PKIaas :

The growing prevalence of cloud computing, remote work environments, and advanced
cyber threats has accelerated the shift toward Zero Trust security architectures. Zero Trust
PKI as a Service (PKIaaS) represents an evolution of traditional PKI by embedding it
within a Zero Trust framework, ensuring continuous verification and secure identity
management across all network layers.

Figure : Zero Trust PKIaas

101 | P a g e
Conclusion :
In this chapter we compared Linux OpenSSL and Windows AD CS as PKI solutions for
enterprise, considering their automation, integration, scalability, and security. While
OpenSSL has many options for flexibility, AD CS has a better model for integration with
Active Directory and easier management. We investigated significant risks, such as
misconfigured templates and OCSP vulnerabilities, with proposed mitigation strategies. The
chapter also highlighted the importance of SIEM integration and automation (SOAR) for
proactive defense. Overall, the findings support adopting a secure, scalable, and well-
monitored PKI tailored to enterprise needs.

102 | P a g e
Internship contributions and conclusion
During my internship in the Cybersecurity Department, I worked on real-world scenarios
involving Public Key Infrastructure (PKI) design, attack simulation, and threat monitoring—
closely aligned with the objectives of my final year project. The core of my project involved
deploying and securing a Tier 2 PKI architecture using Windows AD CS and Linux-based
OpenSSL, while integrating SIEM tools (ELK Stack) and configuring OCSP services via
Apache2. This experience exposed me to advanced security topics, including OCSP Relay
attacks and Denial-of-Service (DoS) targeting OCSP responders in Linux environments. On
the Windows side, I simulated ESC1 and ESC7 attacks, which exploit misconfigured
certificate templates within AD CS to gain unauthorized access or escalate privileges.
Working through these attack paths allowed me to implement and test mitigation strategies,
such as applying correct ACLs, enforcing template approvals, and deploying OCSP
responders behind reverse proxies and load balancers. Hands-on configuration with tools like
Apache2 (as a reverse proxy), Winlogbeat (for log forwarding), and ELK (for real-time
monitoring) provided deep insight into how cybersecurity infrastructure is deployed,
maintained, and defended. The practical challenges mirrored my academic design work,
particularly in setting up SIEM alerting, enforcing certificate security policies, and ensuring
high availability and resilience within a PKI environment.
 Technical Mastery : Gained proficiency in managing AD CS, OpenSSL, Apache2,
and log pipelines using Winlogbeat and ELK, focusing on real-time PKI threat
visibility.
 Threat Modeling : Learned to simulate and analyze attacks (OCSP Relay, DDoS,
ESC1/ESC7) using offensive and defensive cybersecurity tools to understand
vulnerabilities and countermeasures.
 Operational Security Awareness : Recognized the importance of certificate template
control, responder placement, and revocation mechanisms to ensure integrity and
availability.
 Collaboration & Problem-Solving : Cooperated with engineers and security
professionals to diagnose and address issues efficiently, improving my soft skills and
technical reasoning.

103 | P a g e
Webography :
https://datatracker.ietf.org/doc/html/rfc5280
https://csrc.nist.gov/glossary/term/public_key_infrastructure
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2019
https://www.kali.org/get-kali/

104 | P a g e
Reference :
Myers, M., Ankney, R., Malpani, A., Galperin, S., & Adams, C. (1999). X.509 Internet public
key infrastructure online certificate status protocol—OCSP. RFC 2560, Internet Engineering
Task Force, June 1999.

AbdelKader Fatima Zahra et Faetan Soumia, memoire de master en informatique année

universitaire 2016/2017, Universite Belhadji Bouchaid d’Ain-Temouchent disponible sur :

N. Miloslavskaya, « Analysis of SIEM Systems and Their Usage in Security

Operations and Security Intelligence Centers », in Biologically Inspired Cognitive
Architectures (BICA) for Young Scientists, 2018, p. 282-288.
P. S. Yadav, “Automation of Digital Certificate Lifecycle: Improving Efficiency and Security
in IT Systems,” J. Math. Comput. Appli., vol. 2, no. 2, pp. 1–4, 2023

D. Petri, Deploying a Two-Tier PKI Hierarchy in Windows Server 2019, Petri IT Knowledge
Base, 2019.

B. Komar, Microsoft Public Key Infrastructure: Building and Managing PKI Solutions with
Windows Server. Microsoft Press, 2008.

Microsoft, “Active Directory Certificate Services Overview,” Microsoft Learn, 2019.

Microsoft, “Configure the Online Responder for OCSP in Windows Server,” Microsoft Learn,
2021.

OpenSSL Project, “OCSP Support in OpenSSL,” OpenSSL Documentation, 2024.

C. Adams et S. Lloyd, Understanding PKI : Concepts, Standards, and Deployment

Considerations. Addison-Wesley, 2003.

J. Viega, M. Messier, et P. Chandra, Network Security with OpenSSL : Cryptography for

Secure Communications. O’Reilly Media, 2002.

A. Albarqi, E. Alzaid, F. Al Ghamdi, S. Asiri, and J. Kar, “Public key infrastructure: A

survey,” Journal of Information Security, vol. 6, no. 1, pp. 31–37, Jan. 2015. doi:
10.4236/jis.2015.61004.

105 | P a g e
Table Abreviation :

Abréviation Signification

PKI Public Key Infrastructure

CA Certificate Authority

RA Registration Authority

CSR Certificate Signing Request

CRL Certificate Revocation List

OCSP Online Certificate Status Protocol

MTLS Mutual Transport Layer Security

CN Common Name

SAN Subject Alternative Name

X.509 Standard for Public Key Certificates

RSA Rivest–Shamir–Adleman
ECC Elliptic Curve Cryptography

TLS Transport Layer Security

ESC1 Exploitation of User Certificate

Template
ESC7 Misconfigured Certificate Template

AD Active Directory

ELK Elasticsearch, Logstash, Kibana

DoS Denial of Service

MITM Man-In-The-Middle

HSM Hardware Security Module

DN Distinguished Name

106 | P a g e
PSPKI PowerShell Public Key Infrastructure

TGT Ticket Granting Ticket (Jeton

d'authentification Kerberos)

EKU Enhanced Key Usage (Utilisation

avancée de la clé dans les certificats)

107 | P a g e