Reading time: 5 minutes

Setting up Audit is one of the key aspects of any security architecture. For ADCS, logging is important as well. You may enable and set up Active Directory Certificate Services auditing using the instructions given in this article.

First thing First!

The first step is to ensure that auditing is enabled on your ADCS servers.

For this, Run the auditpol command and make sure “Registry” and “Certificate Services” advanced auditing are turned on.

Wait, but what is auditpol?

Windows captures logs of all kinds which may not be useful to us and cause a lot of confusion and loss of focus. To address this, Microsoft has introduced auditpol. Auditpol is used to categorize granually these logs at user level.

Remember to refresh the group policy after you have enabled it!

Some more examples to use auditpol are shown below :

Example 1:

Example 2 :

In our ADCS use case we will use:

auditpol /get /category:*

The next step is to enable monitoring using the ADCS snap-in.

To do this, perform the following steps on the ADCS server.

  • Open Server Manager
  • Select Tools -> Certificate Authority
  • Right-click the CA name and select Properties.
  • Select monitor
  • Enable required monitoring settings
  • Backing up and restoring the CA database
  • Change CA configuration
  • Change CA security settings
  • Issuing and managing certificate requests
  • Revoke certificates and publish CRLs
  • Storing and retrieving archived keys
  • Starting and stopping the ADCS

The next step is to enable the certificate template changes using the certutil command.

certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

Some changes can be made directly through the registry, so registry auditing should be enabled. For this you need to:

  • Open regedit on the ADCS server
  • Find below Registry Key
  • HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\
  • Right click on Configuration and select Permissions
  • Click Details
  • Select Monitoring and click Add
  • Set the principal to Authenticated Users and configure the following permissions:
  • set value
  • create subkey
  • fire extinguishing
  • write DAC
  • write owner
  • read control

Restart the server and see your changes. After rebooting, you will see various event IDs in the security log.

Reboot your server and verify the changes. After the reboot, you should see different event IDs in your Security logs.

Now we have the ADCS auditing up and running.

You can also sieve the audit logs via Azure Arc and Azure Sentinel as well using “Data Collector Rules” in MS Azure.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download
Encryption Services

About the Author

Gopal is a data protection senior consultant at Encryption Consulting LLC working with PKI and other services.

Reading time: 5 minutes

In the modern world, Google Play App is widely used by developers to publish their applications with Google Android. However, when it comes to publishing it, a few nuances must be kept in mind for better security. One such is a self-signed certificate.

Self-signed certificates are generally not used in the TLS world (except for testing purposes). However, in codesigning, it is still used. Especially in the Android world, where the self-signed key is used for the “upload key .”Let’s explore how we securely generate the “upload key” but before it…

What is Upload Key?

Upload key is the new method of uploading APKs (Android Package Kit) to Google Play App Signing for publishing it to users. The upload key establishes trust between your enterprise and Google to upload an Android bundle. The Android bundle must be signed using the upload key before uploading it to the Play Console. It is entirely different from the app signing key used to sign the android bundle for distribution.

Thus, Play App Signing uses two keys: the app signing key and the upload key. We will be referencing only the Upload Key for this article.

Below is a figure to illustrate the signing flow in Android:

Why use Upload Key?

If you continue using your app signing key for your releases, you run the risk that the key might leak due to human error. However, suppose you use a separate upload key for signing the binaries you produce on your machine.

In that case, even if the upload key is compromised, it cannot be used by a malicious third party to create APKs impersonating your own. As a result, using a separate upload key is considered a best practice.

Always use the option “Export and Upload a key from Java Keystore” from a security point of view.

But how do we create an upload Key?

Self-signed certificates are used to generate an upload key. We will first discuss the simplistic way generally used to create a self-signed key via OpenSSL and later discuss the flaw and solution behind this approach:

A simplistic way to create a self-signed key via OpenSSL 

Generation of Private Key

First, we create a private key. The below command creates a 4096-bit RSA private key (.key) with the OpenSSL command:

openssl genrsa -out upload.key 4096

If we want private key encrypted, add the -des3 option to the command.

openssl genrsa -des3 -out upload.key 4096

A side-effect of the pass-phrased private key is that Apache requires the passphrase each time the web server starts. Obviously, this is not always practical as the person entering the data isn’t always around to type in the passphrase, such as after a reboot or crash.

Creating a Certificate Signing Request

You need a Certificate Signing Request (CSR) if you want your certificate signed. The CSR contains your public key and additional information (organization, country, etc.)

Let us create a CSR (upload.csr) from our existing private key:

openssl req -key upload.key -new -out upload.csr

Obtaining certificate from CSR and Key generated

Once the CSR and Private Key are generated, the next step is to create the certificate. The below command generates the certificate with 365 days validity:

openssl x509 -req -days 365 -in upload.csr -signkey upload.key -out upload.crt

The certificate received is in .crt format, having no private key, and we want a .pfx format (as it contains a private key) to sign files. We will use the below command to convert it into pfx:

openssl pkcs12 -inkey upload.key -in upload.crt -export -out upload.pfx

Once the password is provided, .pfx file will be generated.

This pfx file is then supposed to sign the Android Bundle.

Sounds good, right? However, the files signed via this certificate are not accepted in Playstore. This is because the self-signed certificate does not contain Key Usage and Enhanced Key Usage extensions. To see this, open Certificates in the MMC (Microsoft Management Console) and load the Certificates snap-in. After opening the certificate, click the Details tab.

But, What are Key Usage Extensions?

Key usage (KU) extensions define the purpose of the public key contained in a certificate. A single key should be used for only one purpose.

How many Key Usage extensions are available, and which one should I choose?

As per RFC 5280 (Key Usage), below key usage extensions are available:

  • Digital signature
  • Non-repudiation
  • Key encipherment
  • Data encipherment
  • Key agreement
  • Certificate signing
  • CRL signing
  • Encipher only
  • Decipher only

Similarly for Extended key usage (EKU), depending upon the use case, below values must be chosen:

Extended keyEnable for these key usage extensions
TLS Web server authenticationDigital signature, key encipherment or key agreement
TLS Web client authenticationDigital signature and/or key agreement
Sign (downloadable) executable codeDigital signature
Email protectionDigital signature, non-repudiation, and/or key encipherment or key agreement
IPSEC End System (host or router)Digital signature and/or key encipherment or key agreement
IPSEC TunnelDigital signature and/or key encipherment or key agreement

Similarly for Extended key usage (EKU), depending upon the use case, below values must be chosen:

Extended keyEnable for these key usage extensions
IPSEC UserDigital signature and/or key encipherment or key agreement
TimestampingDigital signature, non-repudiation.

Thus, for code signing use case, we require Digital Signature as Key Usage and Code Signing as Enhanced Key Usage

Now, How do I add KU and EKU extensions in my certificate?

To add them, we need to run below command in OpenSSL:

openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out server.pem -days 365  -subj /CN=Cert_Name/C=US/OU=Your_OU/O=Your_org_name -addext “keyUsage = digitalSignature” -addext “extendedKeyUsage = Code Signing”

Where:

CN = Common Name of the certificate (Generally organization name in code signing)

C= Country name

OU = Organization Unit (e.g., Engineering, IT, etc.)

O= Organization Name

And this will generate the requisite code signing certificate with Key Usage and Enhanced Key Usage extension

This certificate can now be successfully used to upload Android bundle to Google Play App Signing Console.

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download
Encryption Services

About the Author

Gopal is a data protection senior consultant at Encryption Consulting LLC working with PKI and other services.

Let's talk