Note:

Use OCI Certificates Service to Issue an Internal Certificate for Website Hosted on IIS Server

Introduction

Oracle Cloud Infrastructure (OCI) Certificates is a service for creating and managing Transport Layer Security (TLS) certificates. The service enables organizations to create private Certificate Authority (CA) hierarchies and TLS certificates that can be deployed and renewed automatically in the customer tenancy, integrated with OCI services such as OCI Load Balancer and OCI API Gateway. We can also use this service to generate certificates for our internal web servers hosted on Internet Information Services (IIS), Apache, or nginx.

Objective

In this tutorial, we describe how to use OCI Certificates to issue an internal certificate to be used to host a TLS/SSL protected website on a windows IIS server. We will discuss the two options.

Prerequisites

Note: Do not enter confidential information.

Task 1: Create a Certificate Authority

We need to create a CA whether we are issuing a certificate using CSR or directly by OCI Certificates CA. For more information on how to configure a CA, see Creating a Certificate Authority.

Use OCI Certificates to create a root CA or a subordinate CA. You must have a root CA to create a subordinate CA. A single-tier hierarchy consists of one CA. The single CA is both a root CA and an issuing CA. A root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the root CA, trust any certificates issued by the CA hierarchy. The issuing CA is a CA that issues certificates to end entities. However, a two-tier hierarchy is a design that meets most companies needs. In this design there is a root CA and a subordinate, issuing CA. The level of security is increased because the root CA and issuing CA roles are separated. Creation of a CA requires you to have access to an existing hardware-protected, asymmetric encryption key from OCI Vault. For more information, see Overview of OCI Vault.

  1. Open the navigation menu and click Identity & Security.

  2. Under Certificates, click Certificate Authorities.

  3. Click Create Certificate Authority.

  4. Click Compartment, and then select the compartment where you want to create the CA.

  5. Under Certificate Authority Type, select the type of CA from the following options.

    1. Root Certificate Authority: The CA at the top of the hierarchy in a chain of CAs.

    2. Subordinate Certificate Authority: Any CA that is not the root CA in a hierarchy containing other CAs.

  6. Enter a display Name for the CA. This name helps you identify the CA for administrative purposes but does not appear as part of the CA certificate.

  7. (Optional) Enter a Description to help identify the CA. This description helps you identify the CA, but doesn’t appear as part of the CA certificate.

  8. (Optional) To apply tags, click Show Tagging. For more information, see Resource Tags, and then click Next.

  9. Enter subject information this includes at least a common name to identify the owner of the CA certificate. Depending on the certificate’s intended use, the subject might identify a person, organization, or computer endpoint. The format of the subject information must conform to RFC 5280 standards. You can use wildcards to issue a certificate for multiple domain or subdomain names.

  10. (Optional) Enter more CA subject information, click Show Additional Fields. For details about each of the values in a subject distinguished name and click Next.

  11. (Optional) Click Not Valid Before, and then specify the UTC time and date when you want to begin using the CA. If you do not specify a date, then the CA validity period begins immediately.

  12. Click Not Valid After, and then specify the date after which the CA can no longer be used to issue or validate subordinate CAs or certificates.

    Note: You must specify a date at least one day later than the starting date of the validity period. You cannot specify a date beyond December 31, 2037. Values are rounded up to the nearest second.

  13. If you create a subordinate CA, under Issuer Certificate Authority, specify a parent CA to issue this CA. If you create a root CA, continue to the next step.

  14. Under Vault, select the vault that contains the encryption key that you want to use for the CA certificate. Optional, click Change Compartment to specify a different compartment.

  15. Under Key, select the key in the vault that you want to use. The list includes only the asymmetric keys in the vault because certificates only supports asymmetric keys. You can choose from Rivest-Shamir-Adleman (RSA) keys that are 2048 bits or 4096 bits. You can also choose Elliptic Curve Digital Signature Algorithm (ECDSA) keys that have an elliptic curve ID of NIST_P384. Specifically, the list includes only these types of asymmetric keys that are protected by a Hardware Security Module (HSM). Certificates does not support the use of software-protected keys.

  16. Under Signing Algorithm, select one of the following options, depending on the key algorithm family and click Next.

    • SHA256_WITH_RSA: RSA key with a SHA-256 hash function

    • SHA384_WITH_RSA: RSA key with a SHA-384 hash function

    • SHA512_WITH_RSA: RSA key with a SHA-512 hash function

    • SHA256_WITH_ECDSA: ECDSA key with a SHA-256 hash function

    • SHA384_WITH_ECDSA: ECDSA key with a SHA-384 hash function

    • SHA512_WITH_ECDSA: ECDSA key with a SHA-512 hash function

  17. Configure the expiry rule. Under Maximum Validity Duration for Certificates (Days), specify the maximum number of days that a certificate issued by this CA can be valid. We strongly recommend a validity period of not more than 90 days.

  18. Under Maximum Validity Duration for Subordinate CA (Days), specify the maximum number of days that a CA issued by this CA can be valid to issue other CAs or certificates and click Next.

  19. On the Revocation Configuration page, if you do not want to configure a Certificate Revocation List (CRL), select the Skip Revocation check box. To configure certificate revocation, clear the check box, and then specify a dedicated OCI Object Storage bucket where you plan to store the CRL.

  20. (Optional) Click Change Compartment to find a bucket in a different compartment.

  21. Under Object Name Format, specify the object name. You can include curly braces in the object name to indicate where the service can insert the issuing CA version number. This addition helps prevent the overwriting of an existing CRL whenever you create another CA version.

  22. (Optional) Under Custom Formatted URLs, provide the URL that you want to use with APIs to access the object. This URL is named in certificates as the CRL Distribution Point (CDP). You can include curly braces in the URL to indicate where the service can insert the issuing CA version number. This addition helps avoid overwriting an existing CDP whenever you create another CA version. You can specify an HTTPS URL only if no circular dependencies in the verification of the HTTPS chain exist.

  23. (Optional) To provide another CDP, click + Another URL, and then provide another URL where users can access the CRL and then click Next.

  24. Review the information, and then click Create Certificate Authority.

It can take a while to create certificate-related resources. Once the CA is created you can use one of the following two methods to get a certificate issued for your IIS servers.

Task 2: Get a Certificate Issued by using CSR

Create a CSR on the IIS server, which will also create a private key on the same server. This is a recommended approach that provides us with a standardized way to send the CA your public key as well as some information that identifies your company and domain name.

  1. Create a CSR using IIS, you need to go to Internet Information Services (IIS) Manager and under Connections menu, click the server name and then click Server Certificates.

    Image 1

  2. In the Actions menu, click the Create Certificate Request… and enter all the details as shown below, and then click Next

    Image 2

    Image 3

  3. On the Cryptographic Service Provider Properties, enter the following information and then click Next.

    Image 4

    (Cryptographic provider types are families of cryptographic services providers that share data formats and cryptographic protocols. Data formats include algorithm padding schemes, key lengths, and default modes.)

    Microsoft RSA SChannel Cryptographic Provider is a recommended CSP and should be used unless you have a reason to use any other value. It supports hashing, data signing, and signature verification. The bit length determines the certificate’s encryption strength: the greater the length, the stronger the security. 2048 is recommended for better security.

  4. On the File Name page, under Specify a file name for the certificate request, click the … to browse to a location where you want to save your CSR (save the file as .pem) that concludes the IIS part for now.

    Image 5

  5. We need to log in to our OCI tenancy and import this CSR. By having the CSR file in .pem format you can go to OCI Certificates services, Certificate Authority, Certificates, Create Certificate and select the Issued by Internal CA, managed externally and enter the necessary details as shown below.

    Image 6

  6. On the Certificate Configuration page you have to upload your CSR file created in Task 2.5 in .pem format, click Next and then click Create Certificate.

    Image 7

    Image 8

  7. Now we need to create the .cer of the certificate which can be used on our IIS server to complete the CSR. The .cer file can be obtained directly from the OCI Console from Identity and Security, Certificates, Certificate. Click View Content and download the contents of certificate pem and certificate-chain-pem and create a single file by combining the contents of both with certificate-pem at the top and certificate-chain-pem at the bottom of the file (make sure to save the resultant file as .cer).

  8. Once done you can go to the IIS server again and click Complete Certificate Request and provide the .cer file that you created above and provide a friendly name, and then click Next.

    Image 9

    Image 10

    Image 100

  9. You will be able to see the certificate under Server Certificates in IIS and it can be used for your website hosted on IIS by modifying the bindings on the website. Edit the Site Binding and choose the installed certificate.

    Image 11

Task 3: Create a Certificate from OCI Certificates service without the CSR

In this approach you handover the management of the private keys to the Certificate Authority. Generally, CSR is the most recommended way to get a certificate from the CA. If for any reason you could not grab a CSR and want to get a certificate issued, you can use this approach. We will use the CA created above to issue a certificate to our website hosted on IIS. We will provide some important information while issuing the certificate like the Subject Name of our website (iistest.com in my case), Certificate Profile type, Key Algorithm, and the CA to be used.

  1. Navigate to the OCI Console and click Identity & Security.

  2. Under Certificates, click Certificate and then click Create Certificate.

  3. Under Compartment, select the compartment where you want to create the certificate. The certificate can exist in the same compartment as the CA or a different one.

  4. Under Certificate Type, to issue a certificate from OCI Certificates CA that also manages the certificate, click Issued by internal CA.

  5. Enter a display Name for the certificate.

  6. (Optional) Enter a Description to help identify the certificate.

  7. (Optional) To apply tags, click Show Tagging and click Next.

  8. Enter the subject information, which includes a common name to identify the owner of the certificate. Depending on the certificate’s intended use, the subject might identify a person, organization, or computer endpoint. Subject information can also include DNS names or IP addresses as subject alternative names by which the certificate bearer is also known. You can use wildcards to issue a certificate for multiple domain or subdomain names. Specify both the common name as well as the DNS name (under SAN) while creating the certificate. (Some browsers ignore the common name and use the subject name or the SAN name to evaluate the subject information.)

  9. (Optional) To add more subject alternative names, click + Another Subject Alternative Name, choose the type of address, enter the name, and then click Next.

  10. Select a certificate profile type from the following profiles based on the certificate’s intended use.

    • TLS Server or Client: Presented by a server or client for TLS/SSL connections.

    • TLS Server: Presented by a server for TLS/SSL connections.

    • TLS Client: Presented by a client during TLS/SSL connections.

    • TLS Code Sign: Presented by a program to validate its signature.

    Since we are issuing the certificate for a Server we should choose TLS Server profile type here.

  11. To change the CA that issues the certificate, click Issuer Certificate Authority, and then select a CA. If necessary, click Change Compartment, and then choose a different compartment if the CA is in a different compartment from the one you selected for the certificate.

  12. (Optional) Click Not Valid Before, and then enter a date before which the certificate cannot be used to validate the identity of its bearer. If you do not specify a date, the certificate validity period begins immediately. Values are rounded up to the nearest second.

  13. Click Not Valid After, and then change the date after which the certificate is no longer valid proof of the identity of its bearer. You must specify a date at least one day later than the starting date of the validity period. The date must not exceed the expiration of the issuing CA. You also cannot specify a date beyond December 31, 2037. Values are rounded up to the nearest second. Typically, certificates are used for the entirety of the period that they are valid unless something happens to require revocation.

  14. For Key Algorithm, select the algorithm and key length combination that you need for the certificate key pair from the following options.

    • RSA2048: Rivest-Shamir-Adleman (RSA) 2048-bit key

    • RSA4096: RSA 4096-bit key

    • ECDSA_P256: ECDSA key with a P256 curve ID

    • ECDSA_P384: ECDSA key with a P384 curve ID

  15. (Optional) Click Show Additional Fields, and then under Signature Algorithm, choose one of the following signing algorithms, depending on the key, and then click Next.

    • SHA256_WITH_RSA: Rivest-Shamir-Adleman (RSA) key with a SHA-256 hash function

    • SHA384_WITH_RSA: RSA key with a SHA-384 hash function

    • SHA512_WITH_RSA: RSA key with a SHA-512 hash function

    • SHA256_WITH_ECDSA: ECDSA key with a SHA-256 hash function

    • SHA384_WITH_ECDSA: ECDSA key with a SHA-384 hash function

    • SHA512_WITH_ECDSA: ECDSA key with a SHA-512 hash function

  16. To configure automatic renewal of the certificate to avoid disruption in its use, specify a nonzero value for the following settings, and then click Next.

    • Renewal Interval (Days): How frequently the certificate is renewed.

    • Advance Renewal Period (Days): The number of days before the certificate expiration that renewal happens.

      For sufficient flexibility, renew the certificate before the end of its validity period and with enough advance renewal time in case of failures. A certificate that expires before the service can successfully renew it can result in service disruptions.

      Note: The certificate will not be auto-renewed on the IIS server. You need to grab the new version of the certificate and re-upload it on the IIS server again when the certificate expires.

  17. Review all the information, and then click Create Certificate.

  18. After the certificate is created we need to create the .pem of the certificate which can be then installed on our IIS server. To create the .pem file we need to grab the cert.pem and the private key.pem of the certificate that we created above. The cert.pem can be obtained directly from the OCI Console from Identity and Security, Certificates, Certificate, View Content and download the contents of certificate pem and certificate-chain-pem and create a single file by combining the contents of both with certificate-pem at the top and certificate-chain-pem at the bottom of the file. For grabbing the private key we can use OCI CLI of our own OCI Cloud Shell and run the below command.

    oci certificates certificate-bundle get --certificate-id=ocid1.certificate.XXXXXXX --bundle-type=CERTIFICATE_CONTENT_WITH_PRIVATE_KEY

  19. You need to copy the contents of the private-key-pem under the Data Section of the command output and save it as a .pem file (say private.pem). Once we have both cert.pem and private.pem files we can use OpenSSL to generate a .pfx file. While copying the contents of the private-key-pem file you might need to remove the \n character as it creates some formatting issues.

    Note : OCI CLI , OpenSSL, and lot of other tools are pre-installed in OCI Cloud Shell which can be used to carry out these operations with ease.

    The private key .pem file should look somewhat similar to this:

    Image 12

  20. You can use the following command to grab the .pem file. Use the native OCI Cloud Shell to run all these commands and provide a secure password for your private key. You will need this password while importing the .pem.

    openssl pkcs12 -inkey priv.pem -in cert.pem -export -out iis.pem

    This iis.pem file needs to be copied to the IIS server. We will need to import this iis.pem in the local machine certificate store on the IIS server. I have already installed IIS and created a demo website. Once the certificate is imported, I can go to my website hosted on IIS and edit the Site Binding and choose the installed certificate. Now we are ready to test the website using https (secured http).

    Image 13

Task 4: Test IIS Hosted Website using Secured Http (https)

We have used a basic Hello World site to showcase this demo and placed the root CA certificate (can be exported from the Certificate-chain-pem) in the Trusted Root Certification Authority folder on the local machine certificate store on our client machines used to access this website. This is done because CAs created by OCI Certificates are private CAs and hence are not trusted by the browsers, so we need to add the root CA and intermediate CA (if used) in the Trusted Root Store/Intermediate Store on all the local machines trying to access the website.

Image 14

Acknowledgments

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.