Certificate Usage

Introduction

The future security needs of the RPS security infrastructure are currently planned to depend on a Public Key Infrastructure (PKI). However, the current landscape of development for the project does not allow for the full implementation of PKI. In its absence, a Self-Signed Certificate strategy has been developed as a temporary measure to provide improved security over plain text secrets and ease the future adoption of full PKI.

The RPS Solution uses certificates for a variety of functions, including:

  1. Web Site SSL binding for HTTPS encrypted transport between server (e.g. RPS Website) and client.
  2. RPS Sync Service for client\server authentication between subscriber (e.g. RPS Sync Service on Region) and distributor (e.g. RPS Sync Service on Master) nodes. The certificate thumbprints for all trusted nodes are whitelisted in the RPS CMDB.
  3. Rps Sync Service for HTTPS encrypted transport between server and client.
  4. DSC mof file credentials encryption (By default DSC encrypts the entire mof file).
  5. WinRM for HTTPS encrypted transport between server and client.
  6. SQL for HTTPS encrypted transport between server and client.
  7. Provisioning SSL binding for HTTPS encrypted transport between server (e.g. RPS Provisioning) and client.
Important

Each certificate must have a certificate root that is trusted by the server (i.e. Trusted Root Certification Authorities).

By default, RPS includes a variety of certificates (even self-signed) to showcase functionality, and it is expected that these development or test certificates will be replaced with appropriate secure and trusted certificates to perform the various functions using the roles indicated.

Warning

Use of self-signed or untrustworthy certificates presents a security risk for all assets and functions "secured" by said certificates.

The table below maps certificates in the ContentStore, as well as certificates generated by the deployment, to their role and corresponding function.

Note

The .pfx file is capable of storing both public and private keys whereas the .cer file is generated from the .pfx and contains only the public key.

Certificate roles and functions

Certificate Role Key Usages Enhanced
Key Usages		 Signature
Algorithm		 Provider
Name		 Key
Length		 Scope Other Notes
RpsRoot Certificate Signing,
Off-line CRL Signing,
CRL Signing (06)		 SHA512 SKSP 4096 All Computers At root of
the cert chain
RpsSync Client
Authentication		 SHA256 SKSP 2048 RpsSync hosts Cert:\CurrentUser\My
for Sync account
RpsSyncSSL KeyEncipherment,
DigitalSignature,
NonRepudiation		 SHA256 SKSP 2048 RpsSync hosts RpsSync
HTTPS endpoint
RpsGuiSSL Digital Signature,
Non-Repudiation,
Key Encipherment (e0)		 SHA256 SKSP 2048 RpsGui hosts Rps Gui
HTTPS binding
WinRm Server
Authentication		 SHA256 ECP v1.0 2048 All computers PowerShell
HTTPS endpoint
DscEncryption Key
Encipherment,
Data Encipherment (30)		 SHA256 ECP v1.0 2048 All computers Credential encryption
in DSC .mof files
SqlSSL Server
Authentication		 SHA256 ECP v1.0 2048 SQL hosts SQL HTTPS endpoint
iPxeSSL Digital
Signature,
Non-Repudiation,
Key Encipherment (e0)		 SHA256 SKSP 2048 iPxe hosts iPxe HTTPS endpoint
ProvisioningSSL KeyEncipherment,
DataEncipherment		 Server
Authentication		 SHA256 ECP v1.0 2048 Provisioning
hosts		 Rps Provisioning
endpoint
Note

Key for table above:
SKSP = Microsoft Software Key Storage Provider
ECP v1.0 = Microsoft Enhanced Cryptographic Provider v1.0

Generating certificates

Certificates can be generated as part of the installer process or supplied from an external PKI. By default, the New-RpsNodeConfiguration.ps1 script will generate self-signed certificates for each role and server using the existing configuration data. If external certificates will be used, the certificate data file located at '{ContentRoot}\Setup\Configuration\RpsCertificateData.psd1' will need to be updated to store the certificate role and password information. The certificates themselves must also be stored in the following path: '{ContentRoot}\Certificates'. The naming convention required for each certificate file should be as follows: '{TargetItemName}_{CertificateRole}.pfx/cer'.

Certificate functions

As part of the Rps-Encryption module, the Set-RpsCertificate function allows you to create role driven certificates for use by RPS. This function will create a new certificate as well as import it into an existing Rps Session. For example:

Set-RpsCertificate `
    -Role RpsSync `
    -Path C:\ContentStore\Certificates\RpsSync.pfx `
    -Password $password `
    -SubjectName "CN=RpsSync" `
    -SigningCertificatePath C:\ContentStore\Certificates\RpsRoot.pfx `
    -SigningCertificatePassword $password

Also part of the Rps-Encryption module, the New-RpsCertificate function allows you to create template driven certificates. The function will generate certificates but do not import the certificate into an existing Rps session. For example:

New-RpsCertificate `
    -CertificateType SSL `
    -Password $password `
    -SubjectName "CN=RpsSync" `
    -SigningCertificatePath C:\ContentStore\Certificates\RpsRoot.pfx `
    -SigningCertificatePassword $password

As part of the Rps-Installer module, the Import-RpsCertificate function allows you to import an existing certificate into the Rps CMDB. For example:

Import-RpsCertificate `
    -Name AD.master.rps_DscEncryption `
    -Path C:\ContentStore\Certificates\AD.master.rps_DscEncryption.pfx `
    -Password $password `
    -Role DscEncryption
    -AssignTo (Find-RpsTargetItem -Name AD.master.rps -Type Computer)

The New-RpsCertificate function implements the New-RpsSelfSignedCertificate function in the Rps-Encryption Module. The New-RpsSelfSignedCertificate function is generic and allows the configuration of many different certificate settings.

SQL Encryption

SQL Transparent Data Encryption (TDE) encrypts data and log files to keep database data protected “at rest.” SQL TDE uses a symmetric database encryption key (DEK) stored in the master database to encrypt/decrypt data in real-time. The DEK is secured using a certificate managed by SQL. The database can only be recovered or moved to another instance or server with the exported certificate.

RPS Database Encryption

RPS is configured to use SQL TDE for both the SMA database and the RPS CMDB using DSC and T-SQL. The certificate used to secure the DEK is generated automatically with DSC, is called RpsDatabaseCertificate.crt, and is backed up to disk (by default in C:\Backups\Certificates). The server’s master key is backed up to RpsDatabaseMasterKey.crt using the password supplied for the RPS Configuration.

Warning

The compromise of the TDE certificates could allow malicious users to retrieve unencrypted data. Follow proven certificate management and backup practices to mitigate security vulnerabilities while preserving the ability for a legitimate administrator to restore the RPS CMDB or SMA databases if needed.