#

            ##::[[---  Windows OpenSSL Config  ---]]::##

#####################################################################
                       ##----- Notes -----##
#####################################################################

  # All commands required can be found beginning on line 430


  # BSD/Linux/Mac users:

    # Replace all single/double backslashes with forward slashes. You may also wish to utilize lowercase only,
    # and if utilizing spaces in names, ensure utilization of proper break format, i.e. './Sophos\ UTM\ CA.crt'

    # Ensure EOLs are LF, not CRLF
      # Windows uses CRLF, UNIX utilizes LF


  # Sophos users:

    # If not using SANs, prior to generating user certs, ensure 'x509_extensions = usr_cert_not_dn'
      # This results with 'RFC822 Name = user@email.com' in the SubjectAlternativeName of the certificate.
        # Without this, it will be impossible to authenticate to VPNs on Sophos.

    # Intermediate CAs & Intermediate CA client certs CANNOT be utilized on Sophos UTM due to how Sophos authenticates.
      # Only exception is the WebAdmin certificate, which can be signed by a Public ICA authority for a FQDN.
        # For chain of trust to be maintained, CA & ICA must be installed on devices accessing the WebAdmin/User Portal.


#####################################################################
             ##----- Establish Build Variables -----##
#####################################################################

dir                             = .
cnf                             = /etc/ssl/openssl.cnf
CNF                             = $dir\\openssl.cnf


#####################################################################
           ##----- Establish CA Profile and Policy -----##
#####################################################################

[ default ]
UTM                             = "Sophos UTM CA"
WRT                             = "Router 2 ICA"
VPN                             = "Router 2 VPN ICA"

[ ca ]
default_ca                      = CA_default


#####################################################################

[ CA_default ]
certs                           = $dir\\cert
new_certs_dir                   = $dir

database                        = $dir\\index
RANDFILE                        = $dir\\rand
serial                          = $dir\\serial

crldir                          = $dir\\crl
crlnumber                       = $crldir\\crlnumber
crl                             = $crldir\\ca.crl.pem
default_crl_days                = 3650

certificate                     = "$dir\\ca\\$UTM.crt.pem"
private_key                     = "$dir\\ca\\$UTM.key.pem"

default_days                    = 3650
preserve                        = no
default_md                      = sha512

x509_extensions                 = usr_cert_not_dn
copy_extensions                 = copy
unique_subject                  = yes

policy                          = policy_match
name_opt                        = esc_2253,esc_ctrl,esc_msb,sep_comma_plus_space,ignore_type
cert_opt                        = ca_default


#####################################################################

[ policy_match ]
countryName                     = match
stateOrProvinceName             = match
organizationName                = match
organizationalUnitName          = match
commonName                      = supplied
emailAddress                    = optional

[ policy_supply ]
countryName                     = match
stateOrProvinceName             = match
organizationName                = match
organizationalUnitName          = match
commonName                      = optional
emailAddress                    = optional


#####################################################################
            ##----- Establish Certificate Options -----#
#--------------------------------------------------------------------

    # If you plan on using TLS ECDHE or ECDH, the bits and hash must exceed the value you wish to have.

      # For example, if one wants 2048bit encryption with a SHA256 hash, encryption value must be
      # greater than 2048 (3072 or 4096) with a hash greater than SHA256 (SHA384 or SHA512).
        # x64 machines can almost always process SHA512 faster than SHA256.

    # If you're not planning on using TLS ECDHE or ECDH, a key larger than 2048bit isn't necessary.

    # Encrypt key is not currently commmented out; however, as one does not want a server's key to have
    # an encrypted password, when creating the key for the server, add -nodes to the Request command.


[ req ]
default_bits                    = 2048
default_keyfile                 = private.key.pem

preserve                        = no
default_md                      = sha512

string_mask                     = utf8only
utf8                            = yes
distinguished_name              = req_distinguished_name
attributes                      = req_attributes
req_extensions                  = v3_req
x509_extensions                 = v3_ca
copy_extensions                 = copy
encrypt_key                     = yes

[ req_attributes ]
 challengePassword              =
 challengePassword_min          = 12
 challengePassword_max          = 40


#####################################################################

[ req_distinguished_name ]

countryName                     = Country
countryName_max                 = 2
stateOrProvinceName             = State
localityName                    = Locality
0.organizationName              = Organization
organizationalUnitName          = Organizational Unit
commonName                      = Common Name
commonName_max                  = 64
emailAddres                     = Email
emailAddress_max                = 64

countryName_default             = xx
stateOrProvinceName_default     = State
localityName_default            = Locality
0.organizationName_default      = Sophos UTM
organizationalUnitName_default  = LAN


#####################################################################
      ##----- Establish SubjectAltName (SAN) Profiles -----##
#####################################################################

  # All server certs with WebUIs should have their loopback IP specified in their SAN profile
    # This prevents certificate errors if connecting to the device, router, or server via an SSH tunnel
      # Certain OS CA certs must have the loopback IP specified in SAN profile (i.e. Sophos UTM's CA)

  # Provided one utilizes the SAN profile, Common Names can be whatever one wishes (i.e. not the DNS or IP)
    # SANs can be: email (an email address), URI (a uniform resource indicator), DNS (a DNS domain name),
    # RID (a registered ID: OBJECT IDENTIFIER), IP (an IP address), dirName (a distinguished name), and otherName.


#--------------------------------------------------------------------
               ##----- Certificate Authorities -----##
#--------------------------------------------------------------------

# Main #
  [ alt_ca_main ]
  DNS.1                 = Router.1
  IP.1                  = 127.0.0.1

# Router 2 #
  [ alt_ica_router2 ]
  DNS.1                 = Router.2
  IP.1                  = 127.0.0.1

# Code Signing #
  [ alt_signing_ica ]
  DNS.1                 = Code-Signing

#--------------------------------------------------------------------
            ##----- Certificate Authority Clients -----##
#--------------------------------------------------------------------

# Main #

  # Servers #
    [ alt_sophos ]
    IP.1                = 192.168.2.1
    IP.2                = 127.0.0.1
    DNS.1               = UTM.LEDE
    DNS.2               = your.ddns.com

    [ alt_freenas ]
    IP.1                = 192.168.2.13
    IP.2                = 192.168.2.130
    IP.3                = 127.0.0.1
    DNS.1               = Free.LEDE
    DNS.2               = your-fqdn.com

    [ alt_vpn_server1 ]
    IP.1                = 10.0.0.1
    DNS.1               = your.ddns.com

  # Clients #
    [ alt_vpn1_user1 ]
    email.1             = user1@email.com
    DNS.1               = VPN1-Client1-Device-Hostname1
    DNS.2               = VPN1-Client1-Device-Hostname2


#--------------------------------------------------------------------
     ##----- Intermediate Certificate Authority Clients -----##
#--------------------------------------------------------------------

# Router 2 #

  # Servers #
    [ alt_lede ]
    IP.1                = 192.168.2.2
    IP.2                = 127.0.0.1
    DNS.1               = LAN.LEDE

    [ alt_vpn_server2 ]
    IP.1                = 10.0.1.1
    DNS.1               = your.ddns.com

  # Clients #
    [ alt_vpn2_user1 ]
    DNS.1               = VPNserver-Client1-Device-Hostname
    email.1             = user1@email.com

    [ alt_vpn2_user2 ]
    DNS.1               = VPN2-Client2-Device-Hostname1
    DNS.2               = VPN2-Client2-Device-Hostname2
    email.1             = user2@email.com


# Code Signing #

  # Cert1 #
    [ alt_codesign ]
    email.1             = user@email.com


#####################################################################
     ##----- Establish Certificate Authority V3 Profiles -----##
#--------------------------------------------------------------------

  # These V3 CA profiles must not be modified to contain any more, or any less, KUs

  # These have been configured specifically for security & its imperative no other keyUsages are set
    # For an ICA to be capable of signing additional CAs/ICAs, pathlen number must mirror number of CAs/ICAs
    # it can sign.  By default, all ICAs are set to 0, meaning they can sign certs, but not other CAs/ICAs.


[ v3_ca ]
basicConstraints            = critical, CA:TRUE
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always, issuer:always
subjectAltName              = @alt_ca_main
keyUsage                    = critical, cRLSign, digitalSignature, keyCertSign

[ v3_ica_router2 ]
basicConstraints            = critical, CA:TRUE, pathlen:0
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always, issuer:always
subjectAltName              = @alt_ica_router2
keyUsage                    = critical, cRLSign, digitalSignature, keyCertSign

[ v3_signing_ica ]
basicConstraints            = critical, CA:TRUE, pathlen:0
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always, issuer:always
keyUsage                    = critical, cRLSign, digitalSignature, keyCertSign
subjectAltName              = @alt_signing_ica

[ crl_ext ]
issuerAltName               = issuer:copy
authorityKeyIdentifier      = keyid:always, issuer:always


#####################################################################
    ##----- Establish Generalized V3 Certificate Profiles -----##
#--------------------------------------------------------------------

[ v3_req ]
basicConstraints            = critical, CA:FALSE
subjectKeyIdentifier        = hash

[ usr_cert_dn ]
basicConstraints            = critical, CA:FALSE
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always, issuer:always
keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage            = critical, clientAuth, emailProtection

[ usr_cert_not_dn ]
basicConstraints            = critical, CA:FALSE
subjectKeyIdentifier        = hash
authorityKeyIdentifier      = keyid:always, issuer:always
subjectAltName              = email:copy
keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage            = critical, clientAuth, emailProtection


#####################################################################
      ##----- Establish Client Certificate V3 Profiles -----##
#--------------------------------------------------------------------

  # These V3 profiles should not be modified to contain less than what they are currently configured with.
    # These have been specifically configured with security in mind.

  # All servers capable of TLS should contain all keyUsages, except for dataEncipherment
    # VPN and file servers should not have less than digitalSignature, keyEncipherment, keyAgreement

  # All servers must contain EKU serverAuth
    # All server [VPN] clients must contain EKU clientAuth


#--------------------------------------------------------------------
            ##----- Certificate Authority Clients -----##
#--------------------------------------------------------------------

# Main #

  # Servers #
    [ v3_sophos ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage            = critical, serverAuth
    subjectAltName              = @alt_sophos

    [ v3_freenas ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage            = critical, serverAuth
    subjectAltName              = @alt_freenas

    [ v3_vpn_server1 ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage            = critical, serverAuth
    subjectAltName              = @alt_vpn_server1

  # Clients #
    [ v3_vpn1_user1 ]
    basicConstraints            = critical,CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment
    extendedKeyUsage            = critical, clientAuth
    subjectAltName              = @alt_vpn1_user1


#--------------------------------------------------------------------
      ##----- Intermediate Certificate Authority Clients -----##
#--------------------------------------------------------------------

# Router 2 #

  # Servers #
    [ v3_lede ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage            = critical, serverAuth
    subjectAltName              = @alt_lede

    [ v3_vpn_server2 ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
    extendedKeyUsage            = critical, serverAuth
    subjectAltName              = @alt_vpn_server2

  # Clients #
    [ v3_vpn2_user1 ]
    basicConstraints            = critical,CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment
    extendedKeyUsage            = critical, clientAuth
    subjectAltName              = @alt_vpn2_user1

    [ v3_vpn2_user2 ]
    basicConstraints            = critical,CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature, keyEncipherment
    extendedKeyUsage            = critical, clientAuth
    subjectAltName              = @alt_vpn2_user2


# Code Signing #

  # Certificates #
    [ v3_codesign ]
    basicConstraints            = critical, CA:FALSE
    subjectKeyIdentifier        = hash
    authorityKeyIdentifier      = keyid:always, issuer:always
    keyUsage                    = critical, nonRepudiation, digitalSignature
    extendedKeyUsage            = critical, codeSigning, msCodeInd, msCodeCom, mcCTLSign, timeStamping
    subjectAltName              = @alt_codesign



#####################################################################
#--------------------------------------------------------------------
                  ##----- OpenSSL Commands -----##
#--------------------------------------------------------------------
#####################################################################

  # Prerequisistes:

  # 1. Create 'serial' file: echo 00 > serial

       # This file maintains the serial for the most recent cert, in order to know what serial to next assign.
       # Serial is in hex, not dec[imal] format, & one can choose whichever number one wishes to start at.

  # 2. Create 'crlnumber' file: mkdir crl && echo 01 > crl\crlnumber

       # This file maintains the current serial for the CRL [Certificate Revocation List] certificate
       # A CRL should be generated, but will not be used until one revokes a certificate via one's CA or ICA

  # 3. Create 'index' file (leave blank): echo > index

       # This file maintains an index of all certificates issued and is covered under the Index Section below
       # Maintains a record of all certs issued, and is extremely important if one has revoked a certificate.

  # 4. Create 'rand' file (leave blank): echo > rand

       # File is utilized by for random characters & is querried by openssl during certificate/key creation.


  # ENCRYPT_KEY [Establish Certificate Options] is not currently commented out; Server cert keys should not
  # be created with encryption, so add the additional command option to key creation: -nodes

    # Encrypting a server key will result in the server requiring the passkey every time it's started/restarted;
    # in other words, a massive inconvenience, and potentially destrimental.


  # Provided you utilize the SubjectAltName (SAN) section [highly recommended], the Common Name is not required
  # to be the IP/DNS/FQDN, and can be whatever name you wish it to be


#####################################################################
#--------------------------------------------------------------------
#####################################################################

  # For VPN Server certs:
    # When creating a VPN server cert using 'extendedKeyUsage = serverAuth', in your VPN client config you must
    # change "remote-cert-tls server" to "remote-cert-eku 'TLS Web Server Authentication'" ( see https://www.v13.gr/blog/?p=386 )

  # For BSD/*nix OSes:
    # Certificates should have 644 permissions
      # chmod 644 ./certificate.crt.pem

    # Keys should have 600 permissions
      # chmod 600 ./certificate.key


#--------------------------------------------------------------------
               ## ----- Certificate Authority ----- ##
#--------------------------------------------------------------------

  # Generate CA:

      # CA key should have a secure password of at least 20 characters, containing at least:
        # 2 uppercase letters, 2 lowercase letters, 2 numbers, and 2 symbols


    # Request:
      # openssl req -x509 -new -sha512 -days 3650 -newkey rsa:4096 -keyout CA.key.pem -out CA.crt.pem -config .\openssl.cnf -extensions v3_ca

    # Generate CA CRL Cert:
      # openssl ca -gencrl -keyfile CA.key.pem -cert CA.crt.pem -out CA.crl.pem -config .\openssl.cnf

    # Convert CA CRL Cert to DER CRL:
      # openssl crl -inform PEM -in '.\CA.crl.pem' -outform DER -out '.\CA.crl'


#--------------------------------------------------------------------
        ## ----- Intermediate Certificate Authority ----- ##
#--------------------------------------------------------------------

  # Gernerate Intermediate CA:

    # Intermediate CA key should have a secure password of at least 20 characters, containing at least:
      # 2 uppercase letters, 2 lowercase letters, 2 numbers, and 2 symbols


    # Request:
      # openssl req -out '.\VPN-ICA.csr' -new -days 3650 -sha512 -newkey rsa:4096 -keyout VPN-ICA.key -config .\openssl.cnf -extensions v3_intermediate_ca

    # Sign Intermediate CA with CA:
      # openssl x509 -req -sha512 -days 3650 -in '.\VPN-ICA.csr' -CA CA.crt.pem -CAkey CA.key -CAserial .\serial -out VPN-ICA.crt.pem -extfile .\openssl.cnf -extensions v3_intermediate_ca

    # Generate Intermediate CA CRL Cert:
      # openssl ca -config .\openssl.cnf -gencrl -keyfile VPN-ICA.key -cert VPN-ICA.crt.pem -out '.\VPN-ICA.crl.pem'

    # Convert Intermediate CA CRL Cert to DER CRL:
      # openssl crl -inform PEM -in '.\VPN-ICA.crl.pem' -outform DER -out '.\VPN-ICA.crl'

#--------------------------------------------------------------------

  # Create Concatenated CA - Intermediate CA Certificate Chain:

    # Windows:
      # cmd /c type '.\Router 2 ICA.crt.pem' '.\Sophos UTM CA.crt.pem' > '.\Sophos VPN CA Chain.pem'

    # Linux/BSD:
      # cat './Router 2 ICA.crt.pem' './Sophos UTM CA.crt.pem' > './Sophos VPN CA Chain.pem'

#--------------------------------------------------------------------

  # Export VPN Client with an Intermediate CA:
    # openssl pkcs12 -export -out '.\VPN Client1.p12' -inkey '.\VPN Client1.key.pem' -in '.\VPN Client1.crt.pem' -certfile '.\Sophos VPN CA Chain.crt.pem'

    # The Intermediate CA is still used to sign the certs it issues, however, the CA - Intermediate CA chain cert must
    # be exported with the client cert & key to maintain the chain of trust of Certificate -> Intermediate CA -> CA.
      # The certificate path of the client cert should show a hierarchy of CA -> Intermediate CA -> Client.


#--------------------------------------------------------------------
                ## ----- Client Certificate ----- ##
#--------------------------------------------------------------------

    # For Server certs, add to end of the Request command:  -nodes
      # If a server cert is created with an encrypted key, one will need to manually type in the encryption password
      # whenever starting or restarting the server (inconvenient and impractical for VPN and Web Servers).


  # Request:
    # openssl req -out '.\NextCloud.csr' -new -days 3650 -sha512 -newkey rsa:3072 -keyout '.\NextCloud.key.pem' -config .\openssl.cnf -extensions v3_nextcloud -nodes

    # With multiple common names:
      # openssl req -out '.\Sophos-UTM-VPN-client.csr' -new -days 3650 -sha512 -newkey rsa:3072 \
      # -subj '/C=US/ST=ST/L=Locality/O=Sophos UTM/OU=LAN/CN=UserName/CN=User.Name/CN=User_Name/emailAddress=whatever@whichever.com' \
      # -keyout '.\Sophos-UTM-VPN-client.key.pem' -config .\openssl.cnf -extensions v3_vpn_client

  # Sign:
    # openssl x509 -req -sha512 -days 3650 -in '.\WRT1900ac.csr' -CA '.\Sophos UTM CA.crt.pem' -CAkey '.\Sophos UTM CA.key.pem' -CAserial .\serial -out '.\crt\WRT1900ac.crt.pem' -extfile .\openssl.cnf -extensions v3_nextcloud

  # Export:
    # openssl pkcs12 -export -out '.\NextCloud.p12' -inkey '.\NextCloud.key.pem' -in '.\NextCloud.crt.pem' -certfile CA.crt.pem


#--------------------------------------------------------------------
            ## ----- Verification of Certificates ----- ##
#--------------------------------------------------------------------

  # Verify Certificate Signing Request (CSR):
    # openssl req -text -noout -verify -in CSR.csr

  # Verify Private Key:
    # openssl rsa -check -in private.key

  # Verify Certificate:
    # openssl x509 -text -noout -in certificate.crt

  # Verify PKCS12 Certificate [.pfx/.p12]:
    # openssl pkcs12 -info -in certificate.p12


#--------------------------------------------------------------------
    ## ----- Intermediate CA Android Build Certificates ----- ##
#--------------------------------------------------------------------

    # This will apply to the following six certificates: media, platform, releasekeys, shared, superuser, testkey
      # the following steps will need to be repeated for each of the six


  # Generate Individual intermediate Build CA Request:
    # openssl req -out '.\media.csr' -new -days 3650 -sha512 -config .\openssl.cnf -extensions v3_intermediate_ca -newkey rsa:4096f4 -ouform PEM -keyout '.\media.key.pem'

  # Convert PEM key to PK8:
    # openssl pkcs8 -in media.key.pem -topk8 -outform DER -out media.pk8 -nocrypt

  # Sign Individual intermediate Build CA Request:
    # openssl x509 -req -sha512 -days 3650 -in '.\media.csr' -CA CA.crt.pem -CAkey CA.key -CAserial .\serial -out '.\media.x509.pem' -extfile .\openssl.cnf -extensions v3_intermediate_ca

  # Generate Individual intermediate Build CA CRL Cert:
    # openssl ca -config .\openssl.cnf -gencrl -keyfile '.\media.key.pem' -cert '.\media.x509.pem' -out '.\media.crl.pem' -extfile '.\openssl.cnf' -extensions crl_ext

  # Convert Individual intermediate Build CA CRL Cert to DER crl:
    # openssl crl -inform PEM -in '.\media.crl.pem' -outform DER -out '.\media.crl'

#--------------------------------------------------------------------

  # Concatenated Intermediate Build CA - CA PEM Certificate:

    # Windows:
      # cmd /c type 'media.x509.pem' 'Sophos UTM CA.crt.pem' > 'Android-Media-CA-Chain.pem'

    # Linux/BSD:
      # cat './media.x509.pem' './Sophos UTM CA.crt.pem' > './Android-Media-CA-Chain.pem'

#--------------------------------------------------------------------

  # Create PKCS12 for Import into Keystore:
    # openssl pkcs12 -export -out .\media.p12 -inkey .\media.key.pem -in .\media.x509.pem  -certfile '.\Android-Media-CA-Chain.pem' -password pass:media -name media

    # The Intermediate CA is still used to sign packages/images, however, the CA - Intermediate CA chain cert
    # must be exported with the client cert & key to maintain the certificate chain of trust of: Package/Image -> Intermediate CA -> CA

      # Copy the following files into your build directory (location will vary depending on ROM):

        # For each of the six: *.x509.pem, *.pk8, Android-*-CA-Chain.pem, *.p12
          # i.e. media.x509.pem, media.pk8, Android-Media-CA-Chain.pem, media.p12


    # One example of how to import into keystore prior to build:
      # Source: http://stackoverflow.com/questions/22212869/how-can-i-generate-an-android-keystore-from-a-key-pk8-and-certificate-pem

        # keytool -importkeystore -deststorepass password -destkeystore .keystore -srckeystore media.p12 -srcstoretype PKCS12 -srcstorepass media
        # keytool -list -v -keystore .keystore


#####################################################################
#--------------------------------------------------------------------
#####################################################################

                      ##---- Index File -----##
#--------------------------------------------------------------------

  # If you wish to maintain the index file automatically, you'll need to use 'openssl ca' to sign certs.
  # You can manually maintain the index file, by inputting 1 cert entry per line in the following format:

    # V    261231235959Z           0a    unknown    /C=US/ST=State/L=Locality/O=Sophos UTM/OU=LAN/CN=Cert Common Name/emailaddress=whatever@whichever.com
    # 1    2----------->    3->    4->   5----->    6--------------------------------------------------------------------------------------------------->


      # 1. Status of Certificate:
           # V [Valid] R [Revoked] E [Expired]

      # 2. Expiration Date:
           # Format: YYMMDDHHMMSS followed by 'Z': 2026.12.31 @ 23:59:59

      # 3. Revocation Date [Format: YYMMDDHHMMSSZ,reason]
           # Certain distros error out without a whitespace for 3 in the index file
           # Empty if not revoked, otherwise valid reasons are:
             # keyCompromise
             # CACompromise
             # affiliationChanged
             # superseded
             # cessationOfOperation
             # certificateHold
             # privilegeWithdrawn
             # AACompromise

      # 4. Serial number in hex format: 0a is hex for 10
           # Windows:
             # Calculator has programmer feature which can convert dec <-> hex
           # Linux/BSD:
             # cli hex -> dec:
               # printf '%d\n' 0x0a [returns 10]
             # cli dec -> hex:
               # printf '%x\n' 10 [returns 0a]

      # 5. Certificate Filename or Literal String
           # Certificate filename or literal string 'unknown'

      # 6. Distinguished Name


#--------------------------------------------------------------------
#####################################################################
                      ##----- Key Usage -----##
#--------------------------------------------------------------------


    # !!!  CA / ICA ONLY  !!! #
#--------------------------------------------------------------------

  # These extensions MUST ONLY be used for CA / ICA certificates

    # cRLSign:
      # Is asserted when subject public key is used for verifying signatures on certificate revocation lists.

    # keyCertSign:

      # Is asserted when subject public key is used for verifying signatures on public key certificates.
        # If keyCertSign is asserted, the CA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted.


    # All #
#--------------------------------------------------------------------

  # digitalSignature:

    # Certificates with this flag set can be used to apply a digital signature. Digital signatures are often used for entity
    # authentication and data origin authentication with integrity.
      # Is asserted when subject public key is used for verifying digital signatures, other than signatures on certificates
      # (bit 5) and CRLs (bit 6).

  # nonRepudiation:

    # Certificates with this flag set can be used to sign data as above but the certificate public key may be used to provide
    # non-repudiation services preventing the signing entity from falsely denying some action.
      # Is asserted when subject public key is used to verify digital signatures, other than signatures on certificates (bit 5)
      # and CRLs (bit 6).
        # NOTE: Recent editions of X.509 have renamed the nonRepudiation bit to contentCommitment.

  # keyEncipherment:

    # Certificates with this flag set may be used by the subject to encrypt a symmetric key which is then transferred to the
    # target, decrypted, and subsequently used to encrypt and decrypt data sent between the two entities.
      # Is asserted when subject public key is used for enciphering private or secret keys when an RSA public key is to be
      # used for encrypting a symmetric content-decryption key or an asymmetric private key.

  # dataEncipherment:

    # Certificates with this flag set can be used by the subject to encrypt and decrypt actual application data.
      # Is asserted when subject public key is used for directly enciphering raw user data without the use of an intermediate
      # symmetric cipher.
        # NOTE: Use of this bit extremely uncommon; all applications use key transport / key agreement to establish a symmetric key.

  # keyAgreement:

    # Certificates with this flag set enable the subject to use a key agreement protocol, such as Diffie-Hellman, to establish
    # a symmetric key with a target that may then be used to encrypt and decrypt data sent between the two entities
      # Is asserted when subject public key is used for key agreement (i.e. when a Diffie-Hellman key is used for key management).

  # encipherOnly:

    # Undefined in the absence of the keyAgreement bit (keyAgreement is required).
      # Public key used only for enciphering data while performing key agreement.
        # When encipherOnly is asserted AND keyAgreement also set, subject public key may be used ONLY for enciphering data while
        # performing key agreement.

  # decipherOnly:

    # Undefined in the absence of the keyAgreement bit (keyAgreement is required).
      # Public key used only for deciphering data while performing key agreement.
        # When decipherOnly is asserted AND keyAgreement is also set, subject public key may be used ONLY for deciphering data
        # while performing key agreement.


#--------------------------------------------------------------------
                  ##----- RFC 5280 4.2.1.3 -----##
#--------------------------------------------------------------------

    # https://tools.ietf.org/html/rfc5280

  # id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

    # KeyUsage ::= BIT STRING {
      # digitalSignature        (0),

      # nonRepudiation          (1),
        # NOTE: Recent editions of X.509 have renamed this bit to contentCommitment

      # keyEncipherment         (2),
      # dataEncipherment        (3),
      # keyAgreement            (4),
      # keyCertSign             (5),
      # cRLSign                 (6),
      # encipherOnly            (7),
      # decipherOnly            (8) }


#--------------------------------------------------------------------
#####################################################################
                  ##----- Extended Key Usage -----##
#--------------------------------------------------------------------

  # serverAuth:

    # SSL/TLS Web/VPN Server authentication EKU which is assigned to a server and distinguishes them as a server for which
    # options, clients can authenticate against.  All VPN servers should be signed with this EKU present.
      # This supercedes nscertype as the 'ns' in nscertype stands for NetScape [browser], which hasn't existed for some time.

  # clientAuth:

    # SSL/TLS Web/VPN Client authentication EKU which is assigned to a server client, and distinguishes them as a client only.
      # All VPN clients MUST be signed with this EKU present.

  # codeSigning:
    # Code Signing... self explanatory

  # emailProtection:
    # Email Protection via S/MIME, allows you to send and receive encrypted emails

  # timeStamping:
    # Trusted Timestamping... self explanatory

  # OCSPSigning:
    # OCSP Signing... self explanatory


  # ipsecIKE:

    # IPSec Internet Key Exchange, of which I believe is in the same boat as the three below; however, some research needs
    # to be Performed to determine if this EKU should also no longer be utilized.
      # clientAuth can be utilized in a IPSec VPN client cert.

  # ipsecEndSystem, ipsecTunnel, & ipsecUser:

    # !!! SHOULD NOT BE UTILIZED !!!

      # There were three IPsec-related object identifiers in EKU that were assigned in 1999, and the semantics of these
      # values were never clearly defined. The use of these three EKU values in IKE/IPsec is obsolete and explicitly
      # deprecated by this specification. CAs SHOULD NOT issue certificates for use in IKE with them.


  # msCodeInd:
    # Microsoft Individual Code Signing (authenticode)... self explanatory

  # msCodeCom:
    # Microsoft Commerical Code Signing (authenticode)... self explanatory

  # mcCTLSign:
    # Microsoft Trust List Signing... self explanatory

  # msEFS:
    # Microsoft Encrypted File System... self explanatory



#--------------------------------------------------------------------
                 ##----- RFC 5280 4.2.1.12 -----##
#--------------------------------------------------------------------

    # https://tools.ietf.org/html/rfc5280

  # anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

    # id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

      # id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }

        # TLS WWW server authentication:
          # Key usage bits that may be consistent:
            # digitalSignature, keyEncipherment or keyAgreement

      # id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }

        # TLS WWW client authentication:
          # Key usage bits that may be consistent:
            # digitalSignature and/or keyAgreement

      # id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }

        # Signing of downloadable executable code
          # Key usage bits that may be consistent:
            # digitalSignature

      # id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }

        # Email protection:
          # Key usage bits that may be consistent:
            # digitalSignature, nonRepudiation, and/or (keyEncipherment or keyAgreement)

      # id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }

        # Binding the hash of an object to a time
          # Key usage bits that may be consistent:
            # digitalSignature and/or nonRepudiation

      # id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }

        # Signing OCSP responses:
          # Key usage bits that may be consistent:
            # digitalSignature and/or nonRepudiation


#--------------------------------------------------------------------
#####################################################################
              ##----- Key Exchange Algorithms  -----##
#--------------------------------------------------------------------

    # RSA:

      # Key exchange occurs via encryption of a random value [chosen by the client] via the server public key. This requires the
      # server public key to be an RSA key, and the server certificate must utilize the 'keyAgreement' keyUsage extension).

    # DH_RSA:

      # Key exchange occurs via a static Diffie-Hellman key. Server Public Key must be a Diffie-Hellman key, of which must have
      # been issued by a CA that was using an RSA key signing key.

    # DH_DSA:
      # Like DH_RSA, except that the CA used a DSA key in lieu of RSA.

    # DHE_RSA:

      # Key exchange occurs via an ephemeral Diffie-Hellman; the server dynamically generates & signs a DH public key, sending it to
      # the client. Server Public Key must be an RSA key, and it's certificate must utilize the digitalSignature keyUsage extension

    # DHE_DSA:
      # Like DHE_RSA, except that the CA used a DSA key in lieu of RSA.


#--------------------------------------------------------------------
#####################################################################
        ##----- Elliptic-Curve Key Exchange Algorithms -----##
#--------------------------------------------------------------------

    # ECDH_ECDSA:

      # Like DH_DSA, but with elliptic curves: the server public key must be an ECDH key, with a certificate issued by a CA
      # which utilized an ECDSA public key.

    # ECDH_RSA:
      # Like ECDH_ECDSA, except that the CA used an RSA key

    # ECDHE_ECDSA:

      # The server sends a dynamically generated EC Diffie-Hellman key and signs it with its own ECDSA key. This is equivalent
      # to DHE_DSS, but with elliptic curves for both the Diffie-Hellman and signature.

    # ECDHE_RSA:

      # Like ECDHE_ECDSA, except that the server public key is an RSA key, utilized for signing the ephemeral elliptic-curve
      # Diffie-Hellman key.


#--------------------------------------------------------------------
#####################################################################