SailPoint IIQ | Tomcat Server SSL port 443 configuration

 

Installing a Windows Domain Certificate in Apache Tomcat — Step-by-Step

Below is a cleaned, ordered article-style transcription of the screenshots you provided. Follow these steps to create a keystore, request a certificate from a Windows CA, import the CA response, export the certificate and key, and configure Tomcat to use the certificate.

---

Step1. Configure and install (prerequisites)

1. Install JavaSoft (Oracle) registry keys for AdoptOpenJDK JRE (if not already installed).

2. Download and install KeyStore Explorer from: https://keystore-explorer.org/.

3. In the Tomcat installation directory create a folder named certs and grant write permissions to the account that will run the key/certificate operations and Tomcat.

---

Step2. Create the keystore file (use KeyStore Explorer)

1. Open KeyStore Explorer.

2. File → New → PKCS #12 (create a new PKCS#12 keystore).

3. Tools → Generate Key Pair → choose RSA 2048.

4. Version → Version 3 (this should be the default).

5. Signature Algorithm → SHA-256 with RSA.

6. Validity Period — set e.g. 5 Years and apply (only applicable if you create a self-signed cert).

7. Click the Name (or Distinguished Name) button and set Common Name (CN) to the fully qualified domain name (FQDN) of the server; fill other DN fields as appropriate.

8. Click Add Extensions and add these extensions:

   • Extended Key Usage — TLS Web Server Authentication

   • Key Usage — Digital Signature and Key Encipherment

   • Subject Alternative Name — DNS Name: the server FQDN (and any additional SANs if required)

   • Subject Key Identifier — 160-bit Hash

9. Enter and confirm a key pair password (store securely).

10. Save the keystore in the Tomcat certs directory using a .pfx extension (use the same password you used for the key pair).

---

Step3. Create a Certificate Signing Request (CSR)

1. In KeyStore Explorer, right-click the key pair → Generate CSR.

2. Format: PKCS #10 (default).

3. Signature Algorithm: SHA-256 with RSA (default).

4. Select Add certificate extensions to request if it is not already selected (this will include the SANs and usages you set).

5. Specify an output filename with a .csr extension and save it to the certs folder.

---

Step4. Submit the CSR to your Windows Certificate Authority (CA)

Example CA web path shown in screenshots: https://dc01/certsrv (replace dc01 with your CA host).

1. Open the CA web enrollment page (e.g. https://dc01.corp.com/certsrv).

2. From the CA home page, click Request a certificate.

3. Click Advanced certificate request (link depends on CA configuration).

4. Paste the entire contents of your .csr file into the text box on the CA request page.

5. Choose Web Server as the certificate template (or the correct template for your environment), then Submit.

6. When the certificate is available choose Base 64 encoded and click Download certificate chain (or Download certificate).

7. Download the file, rename it to name-response.cer (or similar) and copy it into your Tomcat certs directory.

---

Step5. Import the CA response into the keystore (KeyStore Explorer)

1. In KeyStore Explorer, right-click the key pair → Import CA Reply → From File.

2. Select the downloaded response .cer file (the CA reply chain).

3. Import and save the keystore file (.pfx) again (this will attach the CA-signed certificate to your private key entry).

---

Step6. Export certificate chain and private key (to files Tomcat can use)

1) Export the certificate chain

1. Right-click the key pair → Export → Export Certificate Chain.

2. Export Length: Entire Chain.

3. Export Format: X.509.

4. Save the exported certificate as name.cer in the Tomcat certs directory.

2) Export the private key

1. Right-click the key pair → Export → Export Private Key → OpenSSL.

2. Uncheck the Encrypt checkbox (if you need an unencrypted PEM private key).

3. Select PEM checkbox if it is not already selected.

4. Save the private key as name.key in the Tomcat certs directory.

5. Restrict file permissions on the private key so only the Tomcat service account (or admin) can read it.

Security note: keep private keys secure. If you must keep them encrypted on disk, adjust Tomcat configuration accordingly.

---

Step7. Update Tomcat server.xml to use the certificate

1. Open PowerShell (or an elevated command prompt) as Administrator.

2. Set-Location (cd) to the Tomcat conf directory (e.g. C:\path\to\tomcat\conf).

3. Make a backup copy of server.xml (e.g. copy server.xml server.xml.bak).

4. Find the commented connector for SSL — e.g. the <Connector port="8443" ...> line for APR/native — copy and paste or uncomment the appropriate Connector block for APR/native or JSSE depending on your Tomcat build.

5. Modify the Connector attributes to point to the exported key and certificate files. For APR/native you typically set:

   • certificateKeyFile="certs/sailpoint.key"

   • certificateFile="certs/sailpoint.cer"

6. If there is a certificateChainFile attribute present, remove it (you exported the full chain into name.cer; configs vary—confirm your Tomcat connector type expects the fields you set).

7. Save server.xml.

8. Restart the Tomcat service to apply the changes.
   

   ---------------------------------------------------------------
   
   Troubleshoot Steps:
   
   

   Issue :
   SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException 
   Failed to initialize component [Connector["https-openssl-apr-443"]]
   org.apache.catalina.LifecycleException: The configured protocol [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library which is not available
   
   Resolution: 
   
   
   

   Enabling Tomcat Native with OpenSSL on Windows

   When running Apache Tomcat on Windows, enabling the Tomcat Native library improves performance and allows the use of OpenSSL for HTTPS connections. Below are the steps to install and configure it for Tomcat 9.0.109 (64-bit, Windows).

   ---

   Step 1: Download Tomcat Native (tcnative)

   Visit the official Apache Tomcat Native downloads page and download the pre-built 64-bit Windows binaries (ZIP).
   The package contains the required tcnative-1.dll.

   ---

   Step 2: Extract the DLL

   Unzip the downloaded archive.
   Inside the bin folder, locate tcnative-1.dll.
   Make sure you are using the 64-bit version since your OS is 64-bit.

   ---

   Step 3: Copy the DLL

   Copy tcnative-1.dll into one of the following directories:

   • C:\Apache\Tomcat\bin (recommended and safe)

   • C:\Windows\System32 (for system-wide access)

   ---

   Step 4: Install OpenSSL Runtime

   Tomcat Native requires OpenSSL.

   1. Download the latest Win64 OpenSSL Light installer from:
      https://slproweb.com/products/Win32OpenSSL.html

   2. Install it (default installation path is usually C:\Program Files\OpenSSL-Win64).

   3. During installation, if prompted, allow it to copy DLLs into the Windows system directory.

   ---

   Step 5: Add OpenSSL to PATH

   1. Open System Properties → Environment Variables.

   2. In the PATH variable, add:

      C:\Program Files\OpenSSL-Win64\bin
      

   3. Save and apply changes.

   ---

   Step 6: Restart Tomcat

   1. Stop the Tomcat service (if running).

   2. Start Tomcat again.

   If everything is configured correctly, the startup log will display messages similar to:

   org.apache.coyote.http11.Http11AprProtocol initialized with OpenSSL
   OpenSSL successfully initialized
   

   At this point, your HTTPS connector (for example, https-openssl-apr-443) should bind successfully.
   
   
   Happy Learning!!

   
   

CyberArk: CyberArk PVWA Integration with ServiceNow Ticketing System

Service Now Ticketing system integrating with CyberArk PAM (Coming soon ...) 

The purpose of integrating CyberArk PVWA (Privileged Vault Web Access) with the ServiceNow Ticketing System is to enforce secure and auditable access to privileged accounts by validating that a legitimate and approved change or incident ticket exists before granting access.

• All privileged access is tied to authorized business activity (via a ServiceNow ticket).

• Access is granted only when a valid, open, and approved ServiceNow ticket exists.

• Organizations meet compliance, audit, and regulatory requirements.

• Unauthorized or ad-hoc access to sensitive accounts is prevented.

• Integration supports Just-In-Time (JIT) access models and enhances accountability.

Phase 1:  ServiceNow Configuration 

1. Dev Tenant Registration. 
2. Service Account Creation 
3. Users & Groups Creation and Management 
4. Create INC, CHG and Management

Fig1 : 

Fig2: 

Fig3: 

Fig4: 

Phase 2:  CyberArk Configuration 

1. Onboard the Service Now Accounts (Local Under application | Domain User Under Domain Platform) 
2. Enable ServiceNow and configure on PVWA. 
3. 
   
   

Fig1:

Fig2:

Fig3:

Fig4:

Fig5:

Fig6: 

Fig7:

Fig8:

Fig9:

Phase 3:  Testing & Validation

Fig1:

Fig2:

Fig3:

Fig4:

Fig5: 

How To BYPASS the Ticket

Fig1: ( Phase2 : Fig4 is the configuration) 

Fig2:  

References: 

1. CyberArk: Integrate with Enterprise Ticketing Systems | CyberArk Docs

2. CyberArk: ServiceNow Ticketing System | CyberArk Docs

3. Community: CyberArk Integration with ServiceNow Ticketing System Walkthrough

Note: CyberArk should support only INC and CHG items only. 

Useful Information: 

Types tickets with tables Names

• INC – Incident Ticket

• INTSK – Incident Task

• RITM – Service Catalog Request

• TASK – Catalog Task

• CHG – Change Request

• CTASK – Change Task

• PRB – Problem Ticket

• PTASK – Problem Task
  

  
  

Happy Learning!!

CyberArk: CyberArk PVWA integrating with OKTA SAML

 Integrating CyberArk PVWA 14.4 with Okta SAML for Secure Single Sign-On and MFA

Integrating CyberArk Password Vault Web Access (PVWA) 14.4 with Okta SAML 2.0 enables secure and seamless Single Sign-On (SSO) for privileged users. This guide provides a step-by-step walkthrough to configure CyberArk as a SAML Service Provider and Okta as the Identity Provider (IdP), ensuring efficient and secure authentication.

Overview

Using SAML integration with Okta allows organizations to centralize identity management, enhance authentication security, and streamline user access to CyberArk. The integration also supports federated user provisioning and group-based access control.

Phase 1: Prerequisites

Ensure the following requirements are met before beginning the integration:

• CyberArk PVWA version 14.4 or later is installed and operational.
• Okta administrator access is available.
• A test user exists in both CyberArk and Okta.
• HTTPS is enabled for PVWA, as SAML requires secure communication.

Phase 2: Configure CyberArk PVWA for SAML

Step A: Enable SAML in PVWA Configuration

• Log in to CyberArk PVWA as an administrator.
• Navigate to Administration > Configuration Options > Options.
• Under Authentication Methods, expand saml:
• Set Enabled to Yes.
• Optionally, configure the LogoffUrl with your Okta logout URL if Single Logout (SLO) is required.
• Add your Okta domain (e.g., *.okta.com) to the AllowedReferrer list under Access Restriction.
• Click Apply to save the changes.

Step B: Configure the saml.config File

The saml.config file is located at:

<installation path>\inetpub\wwwroot\PasswordVault\WebUI\Configs\saml.config

Update the following parameters:

• ServiceProvider: Define the Name with the CyberArk PVWA URL.
• PartnerIdentityProvider: Set the Okta SAML metadata URL, SingleSignOnService endpoint, and EntityID.
• Configure certificates if required for signed requests or encrypted assertions.
• Ensure consistency between the ServiceProvider name and the values configured in Okta.

Phase 3: Configure Okta as the Identity Provider

Step A: Create a New SAML 2.0 Application

• Log in to the Okta Admin Console.
• Navigate to Applications > Applications, then click Create App Integration.
• Choose SAML 2.0 and click Next.
• Provide the following details:
• App name: CyberArk PVWA
• Optionally, upload the CyberArk logo.

Step B: Configure SAML Settings

Fill in the required fields:

• Single Sign-On URL: Use the Assertion Consumer Service (ACS) URL from the CyberArk saml.config.
• Audience URI (SP Entity ID): This should match the ServiceProvider Name in the CyberArk configuration.

Step C: Define Attribute Statements

Map Okta user attributes to CyberArk:

  

 

        Step D: Configure Group Attribute Statement (Optional)

        You may define a group filter to manage access control based on Okta groups. For example:

• Name: memberOf
• Filter: Starts with "CyberArk-"

Step E: Assign the Application

Assign the newly created SAML application to the users or groups who require access to CyberArk.

Phase 4: Allow Okta API Calls in PVWA

• In PVWA, navigate to Administration > Configuration Options > Security Settings.
• Under API Security > Allowed Domain, add your Okta domain (e.g., https://yourtenant.okta.com).
• Click Add, then Save.

Phase 5: Test the Integration

Method A: IdP-Initiated SSO

• From the Okta dashboard, click on the CyberArk PVWA application tile.
• You should be redirected and logged into CyberArk PVWA without entering credentials.

Method B: SP-Initiated SSO

• Open the CyberArk PVWA URL directly (e.g., https://pvwa.company.com).
• Choose the Okta authentication method from the login options.
• Authenticate using Okta credentials.

Upon successful authentication, the user should be redirected to the PVWA interface. If user attributes are mapped correctly, federated users may be automatically provisioned in CyberArk.

Important Considerations

• Versions of PVWA earlier than 11.3 use the web.config file for SAML configuration. From version 11.3 onward, saml.config is used.
• In PVWA 14.4 and later, users must have allowed authentication methods explicitly defined.
• During initial configuration, enable SAML debug logging to assist in troubleshooting authentication errors.
• Validate that the system clock is synchronized between PVWA and Okta, as time mismatches can lead to SAML assertion errors.

Reference Screenshots step by Step 

 Onboard the CyberArk Application into OKTA 

 

Enter the SAML SSO URL 
https://cyberarkpam.corp.com/PasswordVault/api/auth/saml/logon
Audience url : PasswordVault

 

1.2. Map the Respective PAM User Group to CyberArk Applications


SAML Configurations on PVWA Server  (saml.config file)
--
<?xml version="1.0"?>
<SAMLConfiguration xmlns="urn:componentspace:SAML:2.0:configuration">
  <ServiceProvider Name="[Enter Provider Name i.e. PasswordVault]" Description="PasswordVault Service Provider" AssertionConsumerServiceUrl="~/api/auth/saml/logon"/>
  <LocalCertificates>
      <Certificate FileName="C:\Stage\certs\pvwa.pfx" Password="Password@1234"/>
    </LocalCertificates> 
  <PartnerIdentityProviders>
    <PartnerIdentityProvider Name="[Enter Entity ID]" SingleSignOnServiceUrl="[Enter SSO Login URL]" SignAuthnRequest="false">
      <PartnerCertificates>
        <Certificate String="[Copy & paste the OKTA Cert code]" />
      </PartnerCertificates>
    </PartnerIdentityProvider>
  </PartnerIdentityProviders>
</SAMLConfiguration>

--

 

 

SAML Authentication Enable on the PVWA Portal. 

 

 

Access Retractions allow (Whitelist) [ Load Balancers, pvwa component url's and SSO OKTA URL]

Testing 
https://cyberarkpam.corp.com/PasswordVault/v10/logon/saml

 

 

References

• CyberArk SAML AuthN Doc: SAML authentication | CyberArk Docs
• Community Ref Doc: PVWA - SAML OKTA integration
• OKTA Ref Doc: Setup SSO

 

Happy Learning!!

---------------------------------------------------------------------------------------------------------------

CyberArk: Windows Authentication in PVWA

When CyberArk Vault is deployed in a Windows environment, Windows Authentication enables seamless access to the Password Vault Web Access (PVWA) interface. Users already authenticated to the Windows domain are automatically logged in to PVWA without needing to enter their credentials again.

---

Phase 1: Enable Windows Authentication in Classic PVWA Interface

Step 1: Log in to PVWA

• Use the predefined Administrator account to log into the PVWA interface.

Step 2: Open System Configuration

• Navigate to the ADMINISTRATION section.

• Open the System Configuration page.

• Click on Options to access the system configuration editor.

Step 3: Enable the Windows Authentication Method

• Expand the Authentication Methods section.

• Select windows from the list of supported authentication methods.

• Set the Enabled property to Yes.

Step 4: Save the Configuration

Choose one of the following:

• Click Apply to save and apply the changes immediately.

• Click Save to save the changes and apply them after the duration defined in the RefreshPeriod parameter.

---

Phase 2: Enable Windows Authentication in PVWA V10 Interface

Note: This method is supported from CyberArk version 9.8 and above.

Step 1: Open IIS Configuration File

• Open applicationHost.config located in:

%WinDir%\System32\Inetsrv\Config\applicationHost.config

• Use Notepad (not Notepad++) with administrative privileges.

Step 2: Add Windows Authentication Configuration

At the end of the configuration file, add the following block:

<location path="Default Web Site/PasswordVault/api/auth/windows/logon">
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
</location>

Step 3: Restart IIS

• Open a Command Prompt as Administrator.

• Run the following command:

iisreset

This restarts the IIS server and applies the updated configuration.

---

Phase 3: Test Windows Authentication in PVWA

1. Open the PVWA in a browser.

2. From the list of available authentication methods, select Windows.

3. If configured correctly, PVWA will automatically authenticate you using your current Windows session without prompting for credentials.
   
   
   

Screenshots for your reference: 

1. Enable the Windows Authentication via PVWA 

2. Configure the windows authentication on ApplicationHost.config 

Using Notepad (not Notepad++), open the IIS configuration file. By default, this is %WinDir%\System32\Inetsrv\Config\applicationHost.config. 

 

2) At the end of the file, add the following lines: 

******************** 

<location path="Default Web Site/PasswordVault/api/auth/windows/logon"> 

<system.webServer> 

<security> 

<authentication> 

<windowsAuthentication enabled="true" /> 

</authentication> 

</security> 

</system.webServer> 

</location> 

******************** 

 

3) Perform an IISRESET. 

 

3. Enable the Windows Authentication for User/group. 

4. Update the Internet option to enable user windows logon with current username and password. 

After doing this Windows Authentication should be working as expected through the new UI.

 

https://cyberarkpam.corp.com/PasswordVault/v10/logon/windows



Happy learning!!

CyberArk: CA Certificate Request & install on Vault Server

Purpose: CA Certificate Request & install on Vault Server

The CACert utility is used to manage and prepare SSL certificates for the CyberArk Vault server. These certificates establish secure channels for Vault communications, allowing secure authentication of clients and third-party systems. The utility helps generate certificate signing requests (CSR), import and install certificates, view or verify certificate details, and manage trusted certificate authorities (CAs).

---

Phase 1: Pre-requisites and Planning

• Ensure Vault is already installed and configured.

• Certificate requirements must align with your organizational policies and CyberArk prerequisites.

• You must have access to a Certificate Authority (CA) to sign CSR files or an externally generated PFX certificate (if importing).

• Know the hostname and IP details for use in the Subject Alternative Name (SAN) field.

---

Phase 2: Create the Vault SSL Certificate

Option A: Generate a CSR and Install a Signed Certificate

Step 1: Generate Certificate Signing Request (CSR)

1. Navigate to the Vault server installation folder (default: C:\Program Files (x86)\PrivateArk\Server).

2. Open Command Prompt as Administrator.

3. Run the following command:

CACert.exe request

You will be prompted for:

• Request output file path and name

• Private key output file path and name

• Common Name (Vault hostname)

• Subject Alternative Names (e.g., DNS:vault.company.com, IP:10.0.0.1)

Step 2: Sign the CSR with Your Organization's CA

• Submit the generated CSR to your organizational CA.

• Ensure the returned certificate and its chain are in Base-64 format.

Step 3: Install the Signed Certificate

1. Transfer the signed certificate and certificate chain to the Vault server.

2. Back up the existing private key, as defined in the ServerPrivateKey field in DBParm.ini.

3. Replace the current private key with the new one if needed.

4. Run the following command to install the certificate:

CACert.exe install

Specify the full path to the new certificate file.

5. Restart the Vault service.

---

Option B: Import an Existing Certificate (.pfx)

1. Transfer the .pfx certificate file and its chain to the Vault server.

2. Back up the current private key (from DBParm.ini).

3. Navigate to the Vault installation folder.

4. Open Command Prompt as Administrator.

5. Run the following command:

CACert.exe import

Specify the full path of the .pfx file when prompted.

6. Restart the Vault service.

---

Phase 3: Certificate Verification

View Installed Certificate

1. Go to C:\Program Files (x86)\PrivateArk\Server\Conf.

2. Open DBParm.ini and locate the ServerCertificateFile entry.

3. Copy that file and rename it to .cer format (e.g., server.cer).

4. Double-click to view it or use certificate tools like Crypto Shell Extensions.

Verify TLS Certificate and Chain

1. Open Command Prompt as Administrator.

2. Navigate to the Vault installation folder.

3. Run:

CACert.exe verify

This verifies the installed Vault server certificate and its full trust chain.

---

Phase 4: CA Certificate Store Management (Optional)

You can manage trusted CA certificates for Vault clients using the following command:

CACert.exe setCA

Options include:

• /certstore to specify which certificate store to use

• /list to list current CA certs

• /add and /remove to manage cert files
  

Screenshots for your Reference:

1. How to request the CSR using CACert.exe 

Note: share the vault.csr certificate the CA Team and Get the certificates from them ( server, chain, caroot ) 

2. How to Install the vault.cer using CACert.exe

Happy learning!!

CyberArk : Cyberark PAM integration with PKI Authentication.

Phase 1: Overview & Purpose

Public Key Infrastructure (PKI) allows CyberArk PVWA to authenticate users based on client certificates issued by a trusted Certificate Authority (CA). During login, a secure SSL/TLS handshake ensures:

• The client presents a valid certificate.

• The server verifies the certificate’s trust chain and details (Subject/UPN).

• Optional: Multi-factor support (certificate + password).

---

Phase 2: Prerequisites

2.1 Vault & PVWA Environment

• CyberArk Vault and PVWA must be fully installed and accessible.

• PVWA must be HTTPS-enabled with a CA-signed SSL certificate (not self-signed).

• Vault must also be TLS-enabled with trusted CA certs.

2.2 LDAP/S Integration (Recommended)

• LDAP integration must be configured.

• Vault users must be:

  • Mapped to LDAP users.

  • AuthMethod set to PKI or PKIPN as appropriate.

2.3 Client Certificate Requirements

Each end-user certificate must:

• Be issued by the same trusted CA configured in PVWA.

• Include the UPN or sAMAccountName in:

  • Subject or SAN (Subject Alternative Name).

• Contain the full chain (Root + Intermediates).

• Be present in the user’s Personal Certificate Store (certmgr.msc > Personal > Certificates).

2.4 Server Certificate Trust Setup

On each PVWA server:

• Import the Root CA and Intermediate CA certificates into:

  • Trusted Root Certification Authorities

  • Intermediate Certification Authorities (Local Computer store)

---

Phase 3: PVWA Configuration Steps

3.1 IIS Setup for SSL + Client Certificates

• Open IIS Manager → Default Web Site > Bindings.

• Bind HTTPS to port 443 using the PVWA SSL certificate.

• In PasswordVault > SSL Settings:

  • Check Require SSL

  • Set Client Certificates to Accept (testing) or Require (production)

3.2 Enable PKI / PKIPN in PVWA UI

• Log in to PVWA as an Admin.

• Go to: Administration > Authentication Methods

• Enable:

  • PKI (Distinguished Name matching)

  • PKIPN (UPN matching from certificate)

3.3 Configure LDAP for PKIPN

In PVWA Admin UI:

• Go to: Administration > LDAP Integration

• Under the appropriate profile (e.g., Microsoft AD):

  • Set UserLogonName = userPrincipalName

  • Under LDAP User Mapping, ensure Vault users can be matched by UPN

In web.config under <appSettings>:

<add key="UsePKIPNAlternateUserName" value="yes"/>

---

🔹 Phase 4: Advanced Configuration (Optional but Recommended)

4.1 Enable Extended Certificate Validation

• In PVWA UI: Administration > Configuration Options > General

• Set ValidatePKICertificate = Yes

Conditions required for validation:

• No Elliptic Curve keys

• Client cert includes Client Authentication in Extended Key Usage

• CA has CA=True in Basic Constraints

• No SHA1/MD5 used in signature

• Cert is not self-signed

4.2 Configure web.config for PKI/PKIPN

Location: C:\inetpub\wwwroot\PasswordVault\web.config

For PKI:
No changes needed in the handler if already using:

xml

<add name="PKIAuth" type="CyberArk.Authentication.PKIAuthentication, CyberArk.Authentication.PKI" preCondition="managedHandler"/>

For PKIPN:
Replace with:

xml

<add name="PKIAuth" type="CyberArk.Authentication.PKIPNAuthentication, CyberArk.Authentication.PKIPN" preCondition="managedHandler"/>

 Also, copy CyberArk.Authentication.PKIPN.dll into:
C:\inetpub\wwwroot\PasswordVault\bin

4.3 Validate Certificate Issuer (Restrict Allowed CA)

In web.config under <appSettings>:

xml

<add key="PKIAuthorizedIssuer" value="CN=Your-CA-Name, DC=domain, DC=com" />

Use either:

• Full Distinguished Name (DN), or

• Simple Common Name (CN)

Examples:

xml

<add key="PKIAuthorizedIssuer" value="CN=corp-DC01-CA, DC=corp, DC=com" />
<add key="PKIAuthorizedIssuer" value="corp-DC01-CA" />

---

Phase 5: Testing & Validation

5.1 Test Login via PVWA

• URL: https://pvwa.domain.com/PasswordVault

• Attach Smart Card or ensure client cert is installed.

• Browser behavior:

  • Either auto-authenticates the user

  • Or prompts user to select a valid certificate

5.2 Troubleshooting

If login fails:

•  Check certificate trust chain

• Verify UPN/DN matches Vault user

• Confirm AuthMethod = PKI or PKIPN

• Ensure IIS client cert mode is correct

• Use supported browsers (Chrome, Edge, IE)

• Review logs:

• C:\inetpub\wwwroot\PasswordVault\Logs

Step by step screenshots for your reference:

--------------------------------------------

1. Vault Configured with CA Certificate 

How to request CA Certificate Request and Install on Vault using Domain (Click Here)   : 

2. Update the Domain Issuer details in the Webcomic file. 

3. update the applicationHost.config

Location: %WinDir%\System32\Inetsrv\Config\applicationHost.config.

4. Import the user (Username) certificate on PVWA and Client Machine (Testing Machine) 

5. Verify the installed certificate is updated in Brower level. 

6. Update the PKI Enable on PVWA Configuration Console

A. General Level 

B. Authentication Level 

7. User Group Mapping with External Authentication Like PKI (On Top-up LDAP) 

8. Login user PVWA with PKI authentication Method

Happy learning!!