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 2 :
In our ADCS use case we will use:
auditpol /get /category:*
The next step is to enable monitoringusing the ADCS snap-in.
To do this, performthefollowing steps on the ADCS server.
Open Server Manager
Select Tools -> Certificate Authority
Right-click the CA name and selectProperties.
Enable requiredmonitoring 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 stoppingthe ADCS
The next step is to enable the certificate template changes using the certutil command.
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:
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?