HPE security service

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude

The HpeSecurityService subsystem is the main entry point to the different security mechanisms protecting the iLO and the platform (chassis and components).

The integrity of components (i.e. add-on cards, adapters) is discussed in the iLO and the SPDM section.

Operating system protection is described in the HTTPS Boot TLS configuration and the Secure Boot Databases sections.

iLO Security State

Starting with HPE iLO 5, the SecurityState property can be modified. The following example retrieves the possible values from an HPE iLO 5 or 6 and an HPE iLO 7, using HPE iLOrest and cURL Redfish clients.

ilorest login ilo-ip -u ilo-user -p password
ilorest select HpeSecurityService.
ilorest info SecurityState
ilorest logout

The following example retrieves the current security state using HPE iLOrest and cURL.

ilorest login ilo-ip -u ilo-user -p password
ilorest select HpeSecurityService.
ilorest get SecurityState --json
ilorest logout

The following example transitions from Production to HighSecurity

ilorest login ilo-ip -u ilo-user -p password
ilorest select HpeSecurityService.
ilorest set SecurityState="HighSecurity"
ilorest commit
ilorest logout

Allowed Transitions

HPE iLO 5 and 6

HPE iLO 7

In-band management of iLO 5 and 6

This paragraph concerns only HPE iLO 5 and iLO 6. Refer to the next paragraph for in-band management of HPE iLO 7 and later.

With iLO 5 and 6 in Production security state , privileged OS users (i.e. root, Administrator) can communicate with their local iLO (in-band management) via the Channel Interface (CHIF) without supplying any credential, only when the RequireHostAuthentication property is set to False (default value).

With iLO 5 and 6 in HighSecurity state , privileged OS users (i.e. root, Administrator) can communicate with their local iLO via CHIF without supplying any credential when the RequireHostAuthentication property is set to False.

With iLO 5 and 6 in FIPS security state and higher, all OS users must provide valid credentials when willing to communicate with local iLO (in-band) via CHIF

In iLO 5 and 6 based servers, regardless the value of the security state , OS users must supply valid credentials when willing to communicate with local iLO (in-band) via the Virtual NIC.

The following example retrieves the value of the SecurityState and the RequireHostAuthentication properties with cURL and iLOrest from a remote iLO 6.

curl --insecure --silent --user ilo-user:password \
     'https://ilo-ip/redfish/v1/Managers/1/SecurityService/' |  jq '{SecurityState}'
{
  "SecurityState": "HighSecurity"
}

curl --insecure --silent --user ilo-user:password \
     'https://ilo-ip/redfish/v1/Managers/1/' | jq '.Oem.Hpe | {RequireHostAuthentication}'
{
  "RequireHostAuthentication": true }

From the local OS of a system with its iLO in HighSecurity state and RequireHostAuthentication set to true, when logged as a privileged user (root), the following example tries to modify the value of a property using iLOrest and without providing any credential.

root> whoami
root
root> ilorest --verbose get Oem/Hpe/RequireHostAuthentication --select Manager.

Local login initiated...
High security mode [4] or Host Authentication has been enabled. Please provide valid credentials.
iLORest return code: 75

The following example disables host authentication from a remote system using cURL and iLOrest.

curl --insecure --silent --user ilo-user:password       \
     --header 'Content-Type: Application/json'            \
     --request PATCH                                      \
     --location 'https://ilo-ip/redfish/v1/Managers/1/'  \
     --data '{"Oem": {"Hpe": {"RequireHostAuthentication": false}}}' 

From the OS of a system with iLO in HighSecurity state and RequireHostAuthentication set to false, logged as a privileged OS user (root), the following example can retrieve a property value without supplying any credential.

root> whoami
root
root> ilorest get Oem/Hpe/RequireHostAuthentication --select Manager.
Discovering data...Done
Oem=
     Hpe=
          RequireHostAuthentication=False

root> ilorest logout
logging session out. 

user> whoami
user
user>ilorest --verbose get Oem/Hpe/RequireHostAuthentication --select Manager. 

Local login initiated...

Both remote and local mode is accessible when RESTful Interface Tool is run as administrator. Only remote mode is available for non-admin user groups.
iLORest return code: 5

When performing local (via CHIF) BIOS configuration changes, the following conditions apply:

Refer to the Roles and privileges paragraph for more detail on this topic.

Transitioning to HPE iLO 7

With the introduction of HPE iLO 7, the HPE Channel Interface (CHIF) between the OS and iLO has been removed. As a consequence, in-band management of iLO 7 based servers can only occur via the Virtual NIC (vNIC).

Virtual NIC is more restrictive in terms of authentication than CHIF; Host Redfish clients must always authenticate before being able to perform Redfish requests through this communication path. This is not the case with iLO 5 and iLO 6 as explained above.

Application accounts

With HPE iLO 7, the enforcement of authentication before any in-band communication is also valid for applications running in the host. Host applications willing to use vNIC to communicate with iLO can be scripts, binary programs like iLOrest , system services like the HPE Agentless Management Service (AMS) or asynchronously launched applications like the Software Update Tool ( iSUT) and the HPE Smart Update Manager ( SUM).

In order to provide those applications an in-band access to iLO without any human interaction and without the need for retrieving credentials from unsecure locations, a companion application account and an associated application token can be created during the application installation or at a later time. Application accounts are slightly different from iLO user accounts. This is why they are described in a specific HPE OEM schema . Application tokens are securely stored in the Truted Platform Module (TPM) of the server.

The creation of application accounts (and associated application tokens) is performed only once, using the credentials of an already existing iLO user. Upon successful identification, iLO creates the application accounts and sends back the application token that the application stores securely in the TPM.

Then, when applications need to in-band communicate with iLO, they present their respective application token to the iLO that validates it and replies back with a Redfish session token.

With this process, host applications don't need to wait for a human being or to fetch iLO user credentials from an insecure location to authenticate and create a Redfish session.

Application accounts are listed in the standard ManagerAccountCollection collection . Application accounts are modeled in the OEM HpeiLOAppAccount extension schema.

The following example retrieves the collection of application accounts present in a remote HPE iLO 7.

ilorest login ilo7-ip -u ilo-user -p password
ilorest list Members --select  ManagerAccountCollection. \
        --filter @odata.id="/redfish/v1/AccountService/Oem*" \
        --json
{
  "Members": [
    {
      "@odata.id": "/redfish/v1/AccountService/Oem/Hpe/AppAccounts/65605/"
    },
    {
      "@odata.id": "/redfish/v1/AccountService/Oem/Hpe/AppAccounts/65606/"
    }
  ]
}

The following example retrieves the properties of the Agentless Management Service (AMS) application account, using iLOrest and cURL, and present in a remote HPE iLO 7.

ilorest login ilo7-ip -u ilo-user -p password
ilorest list --select HpeiLOAppAccount --filter HostAppName="AMS" --json
ilorest logout

Installing HPE host applications

With the introduction of HPE iLO 7, the installation scripts of HPE applications needing in-band access iLO have the ability to create an associated application account within the underlying iLO. For this creation to happen, it is necessary to supply the credentials of an already existing iLO user, interactively or through system global variables. Refers to the examples below.

Application account privileges

The following table lists the minimum privileges required by HPE host applications to operate seamlessly trough in-band communication with the underlying iLO.

The following example creates an ilorest-appuser with LoginPriv, UserConfigPriv and iLOConfigPriv privileges. Refer to the iLOrest user guide for the privileges numbering.

ilorest login ilo-ip -u ilo-user -p password
ilorest iloaccounts add ilorest-appuser "iLOrest application user" passwordexample --addprivs 1,3,4
New iLO account ilorest-appuser is added successfully

# View the just created user:
ilorest get --select ManagerAccount. --refresh --filter UserName="ilorest-appuser"  --json
{
  "AccountTypes": [
    "WebUI"
  ],
  "Description": "iLO User Account",
  "Enabled": true,
  "Id": "8",
  "Name": "User Account",
  "Oem": {
    "Hpe": {
      "LoginName": "iLOrest application user",
      "Privileges": {
        "HostBIOSConfigPriv": false,
        "HostNICConfigPriv": false,
        "HostStorageConfigPriv": false,
        "LoginPriv": true,
        "RemoteConsolePriv": false,
        "SystemRecoveryConfigPriv": false,
        "UserConfigPriv": true,
        "VirtualMediaPriv": false,
        "VirtualPowerAndResetPriv": false,
        "iLOConfigPriv": true
      },
      "ServiceAccount": false
    }
  },
  "Password": null,
  "PasswordChangeRequired": false,
  "RoleId": "Administrator",
  "UserName": "ilorest-appuser"
}

ilorest logout

Installation examples

The following example shows an interactive installation of the iLOrest 6.0.0.0 RPM package in an HPE iLO 7 based Linux operating system, with the creation of a application account for further easy in-band management. The credentials supplied for the creation of the application account are the ones of the user created in the previous example (ilorest-appuser).

whoami
root
rpm -ivh ilorest-6.0.0.0-29.x86_64.rpm
warning: ilorest-6.0.0.0-29.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 26c2b797: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:ilorest-6.0.0.0-29               ################################# [100%]

Unable to find an application account. For communication using virtual NIC,
an application account in iLO is required. Creation of the account requires
iLO credentials with 'Administer User Accounts' privilege.

Note: The application account will be automatically removed during uninstallation.

For more information, refer to the documentation.

Proceed with application account creation? (yes/no): yes
Enter iLO username: ilorest-appuser
Enter iLO password (input will be hidden):
Successfully created the application account.
Application installed successfully.

ilorest iloaccounts delete ilorest-appuser

Managing application accounts

The management of application accounts consists of three operations: create, check and delete. The creation can be performed during the installation of the application (previous example) or later, using the Command Line Interface (CLI) associated with the application (i.e. amscli, ilorest)

The following example checks the existence of an application account for the Agentless Management Service and for iLOrest, using their respective CLI.

amscli appaccount check
AppToken for AMS is found in TPM.

The following example demonstrates the flexibility of iLOrest and its associated application account. Without supplying any iLO credentials, it logs out from any existing session, detects the underlying iLO type and then lists all the application accounts and their details. These operations are performed in the OS of an iLO 7 based server.

ilorest logout
Logging session out.

ilorest detectilo
Detecting iLO for this server.
iLO Type: 7

ilorest appaccount details --hostappid all
Application Name: AMS
Application Id: **fea0
App account exists in TPM: yes
App account exists in iLO: yes

Application Name: iLORest
Application Id: **00b5
App account exists in TPM: yes
App account exists in iLO: yes

The following example uses iLOrest to delete its own application account using the last four digits of its host application Id, found in previous example. Then, it checks for its own application account in verbose mode.

The return code is 143 (TOKEN_DOES_NOT_EXIST_ERROR), which is normal because both application account and associated token have just been deleted.

The last step of the following example fails to retrieve all application account details because iLOrest could not create a Redfish session (error 143).

ilorest appaccount delete --hostappid 00b5
Application account has been deleted successfully.

ilorest -vv appaccount exists --self
Application account does not exist for this hostapp.
iLORest return code: 143

ilorest -vv appaccount details --hostappid all
ERROR   : iLORest app account not found. Please create one using ilorest appaccount create to proceed.

iLORest return code: 143

The following example creates an in-band vNIC session for iLOrest, without using its application account (it has been deleted in previous example).

Then, it tries to retrieves the details of all application accounts in underlying iLO 7. The failure is expected because the iLOrest Redfish session has not been created with the help of an application account, and the ilorest appaccount command can only be used during an in-band session created with the help of iLOrest's associated application account.

ilorest login --no_app_account -u ilo_user -p password

Attempt to login with Vnic...
Discovering data...Done

ilorest -vv appaccount details --hostappid all
ERROR   : iLORest app account not found. Please create one using ilorest appaccount create to proceed.

iLORest return code: 143

The following example uses iLOrest to create its own application account. By supplying an iLO user (and password) with the minimum iLO privileges, iLOrest can open a Redfish session, and ask iLO to create the application account and send back the associated application token to be stored in the TPM.

The second command can retrieve the details of all application accounts present in iLO, because the iLOrest Redfish session has been created with the help of its application account.

# Make sure iLOrest is logged out
ilorest logout  

ilorest appaccount create --self -u ilorest-appuser -p password
Application account has been generated and saved successfully.

ilorest appaccount details --hostappid all
Application Name: AMS
Application Id: **fea0
App account exists in TPM: yes
App account exists in iLO: yes

Application Name: iLORest
Application Id: **00b5
App account exists in TPM: yes
App account exists in iLO: yes

iLO TLS versions management

To provide a high degree of privacy and ensure authentication and data integrity in communications between clients (Web and Redfish) and iLO, it is possible to configure different versions of the Transport Layer Security (TLS) protocol using the TLSVersion property of the HpeSecurityService data type.

TLS, formerly called Secure Socket Layer (SSL) is a standard from the Internet Engineering Task Force (IETF).

This paragraph details the TLSversion property which displays the status (Enabled / Disabled) of the supported TLS versions and how they can be modified in the different security states. It corresponds to the Security -> Encryption Settings screen of the HPE iLO graphical user interface.

HPE iLO Standard, that comes with every HPE ProLiant Gen11 or later server, gives customers the ability to configure servers in one of three security states (Production, High Security, and FIPS). With an iLO Advanced license, a fourth security state is available, providing the highest level encryption capabilities of CNSA.

iLO features the following security states:

1. Production
2. High Security
3. FIPS (Federal Information Processing Standards)
4. CNSA (Commercial National Security Algorithm)

For more information on iLO security states, refer to the iLO encryption settings section in the HPE iLO User Guide

Viewing status of TLS versions enabled/disabled

The following example retrieves the status of TLS versions.

GET /redfish/v1/Managers/1/SecurityService/?$select=TLSVersion

Modifying the status of specific TLS versions

TLS versions can only be modified when the iLO is in the Production security state. The following example retrieves the SecurityState property using a generic GET request and the iLOrest command line interface.

GET /redfish/v1/Managers/1/SecurityService/?$select=SecurityState

Enabling/disabling the TLS versions triggers an event and creates an alert for that event. The message arguments include TLS version being modified, its status, and the user who requested for the change for the alert.

Updating TLS versions creates an entry in the Security Logs. Remote event listener systems (i.e. HPE Compute Ops Management) are notified after subscribing to the iLOEvents registry prefix.

Examples of entries (Description) in the Security Log after performing PATCH on TLS versions:

• TLS Version 1.0 is Disabled by: username
• TLS Version 1.0 is Enabled by: username
• TLS Version 1.1 is Disabled by: username
• TLS Version 1.1 is Enabled by: username

Enable/Disable weak iLO ciphers

HPE iLO provides flexibility to enable/disable weaker encryption algorithms, and shorter key lengths in the Production security state. Property DisableWeakCiphers has been added in iLO 5 version 3.01 and iLO 6 version 1.56 under the URI /redfish/v1/Managers/1/SecurityService/ that supports Boolean values i.e.{true} and {false}.

Performing a PATCH on this property enables/disables weak ciphers i.e. TLS1.0 and TLS1.1. For example, PATCH on property DisableWeakCiphers with a false attribute enables weak ciphers whereas true disables weak ciphers resulting in disabling of the TLS support. Upon a successful PATCH operation, iLO resets and the updated values are seen in the next GET request on the same URI(/redfish/v1/Managers/1/SecurityService/).

When DisableWeakCiphers is set to {true} TLS1.0 and TLS1.1 are not usable or configurable in iLO. When DisableWeakCiphers is set to {false} TLS1.0 and TLS1.1 can be configured to enable/disable as per your requirement.

To disable weak ciphers perform PATCH

PATCH /redfish/v1/Managers/1/SecurityService/

To enable and modify weak ciphers(TLS1.0 and TLS1.1) when weak ciphers are disabled.

{
  "DisableWeakCiphers" : false,
  "TLSVersion":{
    "TLS1_0": "Enabled",
    "TLS1_1": "Enabled"
  }
}

TLS/SSL certificates

This paragraph provides information concerning the management of TLS/SSL certificates used to secure the connection between clients (Web and Redfish) and iLO.

HPE iLO implements TLS versions 1.0, 1.1, 1.2 as defined by the Internet Engineering Task Force (IETF). However, because the "SSL" acronym still has so much name recognition, you will find TLS referenced as "TLS/SSL" in this paragraph. Refer to the previous paragraph to manage these versions.

The TLS protocol, regardless its version, can only be used by websites that have a TLS/SSL certificate. A TLS/SSL certificate is like an ID card or a badge that proves someone is who they say they are.

To be valid, TLS/SSL certificates must be signed by a Certificate Authority (CA), and that CA is trusted, all certificates signed by the CA are also trusted. A self-signed certificate is one in which the owner of the certificate acts as its own CA. By default, iLO creates a self-signed certificate for use in TLS/SSL connections. This certificate enables iLO to work without additional configuration steps.

One of the most important piece of information in a TLS/SSL certificate is the website's public key. The public key makes encryption and authentication possible. A user's device views the public key and uses it to establish secure encryption keys with the web server. Meanwhile the web server also has a private key that is kept secret; the private key decrypts data encrypted with the public key.

Obtaining and importing a TLS/SSL certificate

iLO allows you to create a private key and a Certificate Signing Request (CSR) that you can send to a Certificate Authority (CA) and obtain back a trusted/signed TLS/SSL certificate that you can import into iLO.

A signed/trusted TLS/SSL certificate is only valid with the public and secret keys generated with the corresponding CSR. If iLO is reset to the factory default settings, or another CSR is generated before the certificate that corresponds to the previous CSR is imported, the certificate does cannot be imported. In that case, a new CSR must be generated and used to obtain a new signed certificate from a CA.

Generate a Certificate Signing Request

To generate a CSR, you need the following information:

• Organization Name (O) — The name of the company or organization that owns this iLO subsystem.
• Organizational Unit (OU) — (Optional) The unit within the company or organization that owns this iLO subsystem.
• Common Name (CN) — The FQDN of this iLO subsystem.
• Country (C) — The two-character country code that identifies the country where the company or organization that owns this iLO subsystem is located. Enter the two-letter abbreviation in capital letters.
• State (ST) — The state where the company or organization that owns this iLO subsystem is located.
• City or Locality (L) — The city or locality where the company or organization that owns this iLO subsystem is located.
• Include IP - Boolean to include (or not) the iLO IP address in the CSR.

The CSR generation process consists of a POST request toward a Redfish action URI provided by the HpeHttpsCert data type at /redfish/v1/managers/{item}/securityservice/httpscert/.

The following example shows how to generate an iLO 6 CSR with HPE iLOrest. Note that HPE iLOrest requires a specific order of the parameters.

POST {{iloURI}}/redfish/v1/Managers/1/SecurityService/HttpsCert/Actions/
HpeHttpsCert.GenerateCSR

The following example generates an iLO 6 CSR using Python scripts using the HPE and the DMTF Python Redfish libraries.

# This simple Python script uses the HPE Redfish Python Library
# (https://github.com/HewlettPackard/python-ilorest-library) to generate
# an iLO TLS/SSL Certifcate Signing Request (CSR).

# It is based upon the "generate_csr.py" example in
# https://github.com/HewlettPackard/python-ilorest-library/blob/master/examples/Redfish/generate_csr.py

# NOTE: The HPE Redfish Python library cannot co-exist with the
#       DMTF Redfish Python library in the same Python environment.
#       You should uninstall one before installing the other one.
#
# pip uninstall redfish
# pip install python-ilorest-library

# The sources of the HPE Redfish Python library is on GitHub at
# https://github.com/HewlettPackard/python-ilorest-library



# -*- coding: utf-8 -*-
"""
An example of generating a Certificate Signing Request (CSR) for HPE iLO systems
"""
import sys
import json
import time
from redfish import RedfishClient
from redfish.rest.v1 import ServerDownOrUnreachableError

def get_resource_directory(redfishobj):

    try:
        resource_uri = redfishobj.root.obj.Oem.Hpe.Links.ResourceDirectory['@odata.id']
    except KeyError:
        sys.stderr.write("Resource directory is only available on HPE servers.\n")
        return None

    response = redfishobj.get(resource_uri)
    resources = []

    if response.status == 200:
        sys.stdout.write("\tFound resource directory at /redfish/v1/resourcedirectory" + "\n\n")
        resources = response.dict["Instances"]
    else:
        sys.stderr.write("\tResource directory missing at /redfish/v1/resourcedirectory" + "\n")

    return resources

def generate_csr(_redfishobj, csr_file, csr_properties):

    csr_uri = None
    generate_csr_uri = None

    resource_instances = get_resource_directory(_redfishobj)
    if DISABLE_RESOURCE_DIR or not resource_instances:
        #if we do not have a resource directory or want to force it's non use to find the
        #relevant URI
        managers_uri = _redfishobj.root.obj['Managers']['@odata.id']
        managers_response = _redfishobj.get(managers_uri)
        managers_members_uri = next(iter(managers_response.obj['Members']))['@odata.id']
        managers_members_response = _redfishobj.get(managers_members_uri)
        security_service_uri = managers_members_response.obj.Oem.Hpe.Links\
                                                                ['SecurityService']['@odata.id']
        security_service_response = _redfishobj.get(security_service_uri)
        csr_uri = security_service_response.obj.Links['HttpsCert']['@odata.id']
        https_cert_response = _redfishobj.get(csr_uri)
        generate_csr_uri = https_cert_response.obj['Actions']['#HpeHttpsCert.GenerateCSR']\
                                                                                    ['target']
    else:
        #Use Resource directory to find the relevant URI
        for instance in resource_instances:
            if '#HpeHttpsCert.' in instance['@odata.type']:
                csr_uri = instance['@odata.id']
                generate_csr_uri = _redfishobj.get(csr_uri).obj['Actions']\
                                                        ['#HpeHttpsCert.GenerateCSR']['target']
                break

    if generate_csr_uri:
        body = dict()
        body["Action"] = "HpeHttpsCert.GenerateCSR"
        body["City"] = csr_properties["City"]
        body["CommonName"] = csr_properties["CommonName"]
        body["Country"] = csr_properties["Country"]
        body["OrgName"] = csr_properties["OrgName"]
        body["OrgUnit"] = csr_properties["OrgUnit"]
        body["State"] = csr_properties["State"]
        body["IncludeIP"] = csr_properties["IncludeIP"]
        resp = _redfishobj.post(generate_csr_uri, body)
        if resp.status in [200, 201]:
            sys.stdout.write("Generating CSR, this may take a few minutes\n")
            sys.stdout.write("Sleeping for 1 minutes...\n")
            time.sleep(60)
            csr_resp = _redfishobj.get(csr_uri).dict['CertificateSigningRequest']
            with open(csr_file, 'w') as csroutput:
                csroutput.write(csr_resp)
            sys.stdout.write("CSR Data saved to file: '%s'\n" % csr_file)
        else:
            #If iLO responds with soemthing outside of 200 or 201 then lets check the iLO extended
            #info error message to see what went wrong
            if resp.status not in [200, 201]:
                try:
                    print(json.dumps(resp.obj['error']['@Message.ExtendedInfo'], indent=4, \
                                                                                    sort_keys=True))
                except Exception as excp:
                    sys.stderr.write("A response error occurred, unable to access iLO "\
                                     "Extended Message Info...\n")

if __name__ == "__main__":
    # When running on the server locally use the following commented values
    #SYSTEM_URL = None
    #LOGIN_ACCOUNT = None
    #LOGIN_PASSWORD = None

    # When running remotely connect using the secured (https://) address,
    # account name, and password to send https requests
    # SYSTEM_URL acceptable examples:
    # "https://10.0.0.100"
    # "https://ilo.hostname"
    SYSTEM_URL = "https://ilo-ip"
    LOGIN_ACCOUNT = "ilo-user"
    LOGIN_PASSWORD = "password"

    #CSR Dictionary, each value should be updated to reflect the desired CSR
    CSR_DICT = {"City" : "Houston", "CommonName": "ilo-hostname", "Country": "US", \
                "OrgName": "HPE", "OrgUnit": "Compute", "State": "Texas", "IncludeIP": False}

    #After CSR is generated, a file will be created and the CSR will be downloaded
    CSR_FILE = "ilo-hostname.csr"
    # flag to force disable resource directory. Resource directory and associated operations are
    # intended for HPE servers.
    DISABLE_RESOURCE_DIR = False

    try:
        # Create a Redfish client object
        REDFISHOBJ = RedfishClient(base_url=SYSTEM_URL, username=LOGIN_ACCOUNT, \
                                                                            password=LOGIN_PASSWORD)
        # Login with the Redfish client
        REDFISHOBJ.login()
    except ServerDownOrUnreachableError as excp:
        sys.stderr.write("ERROR: server not reachable or does not support RedFish.\n")
        sys.exit()

    generate_csr(REDFISHOBJ, CSR_FILE, CSR_DICT)
    REDFISHOBJ.logout()

Retrieve the CSR and send it to a third party CA

The following example retrieves an iLO 6 CSR with iLOrest and its certificate macro command and then cURL. Both commands place the CSR in a text file. However, the format is different. Namely, iLOrest returns a file with CR-LF line breaks while cURL returns a JSON formatted file with \n as line separators.

GET redfish/v1/Managers/1/SecurityService/HttpsCert/?$select=CertificateSigningRequest

The CSR is now ready to be sent to a Certificate Authority for a certificate generation and signing process.

Importing a signed certificate into iLO

Once the Certificate Authority has returned a signed certificate, you can import it to the corresponding iLO using an ASCII format with LineFeed (LF) characters coded a \n.

sed -E ':a;N;$!ba;s/\r{0,1}\n/\\n/g' certfile.crt > certfile.txt

# Explanation:
# :a Creates a label
# N Joins current line and next one
# $!ba If we are not at last line, perform the following search/replace pattern
# \r{0,1} if \r is present or not

The following example imports a TSL/SSL signed certificate into iLO using the iLOrest certificate command.

POST {{iloURI}}/redfish/v1/Managers/1/SecurityService/HttpsCert/
Actions/HpeHttpsCert.ImportCertificate

Sideloading certificate with private key

For security reasons, you may want to create your custom private key and CSR and import both the private key and the associated signed certificate to the iLO, as mentioned in the Security -> SSL Certificate -> Import an SSL Certificate & Private Key button in the iLO Graphical User Interface.

FILE="filename" 
openssl rsa  -noout -modulus -in private/$FILE.key | openssl md5   # Private key (PEM format)
openssl req  -noout -modulus -in csr/$FILE.csr     | openssl md5   # CSR (PEM format)
openssl x509 -noout -modulus -in certs/$FILE.crt   | openssl md5   # Signed certificate (PEM format)

The following example uploads a certificate along with the private key combined in a single PEM file with CR and LF characters replaced with respectively \r and \n.

cat Certificate.crt PrivateKey.key > CombinedCertPrivateKey.pem

POST {{iloURI}}/redfish/v1/Managers/1/SecurityService/HttpsCert/Actions/HpeHttpsCert.ImportCertificate

Automatic Certificate Enrollment

Starting with HPE iLO 5 version 2.60 introduced the support of the Simple Certificate Enrollment Protocol (SCEP) against the Microsoft Network Device Enrollment Service (NDES). When implemented, this feature allows HPE iLO to obtain and renew TLS/SSL certificate automatically.

By default the feature is disabled. To enable automatic certificate enrollment for iLO, you must first configure the following services on the certificate enrollment server:

• Configure the Certificate Authority (CA).
• Configure NDES. NDES is the Certificate Enrollment Server.

Enabling Automatic Certificate Enrollment

Prerequisites:

• HPE iLO 6
• iLOConfigPriv privilege
• URL of the certificate enrollment server
• Challenge password
• CA certificate of the certificate enrollment server must be imported. (See Obtain a trusted certificate from a Certificate Authority (CA)).
• Configure Certificate Signing Request (CSR)
• A license that supports this feature is installed. For information about the available license types and the features they support, see the licensing documentation.

To enable Automatic Certificate Enrollment, perform PATCH on /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

PATCH /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

Updating certificate enrollment settings

Prerequisites:

• iLOConfigPriv privilege

To view the automatic certificate enrollment settings, perform a GET like in the following example.

GET /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

Modifying Webserver CSR subject contents

To modify the webserver CSR subject contents, perform PATCH on /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

PATCH /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

Renewing automatically managed SSL certificate

When the certificate enrollment service is enabled and the certificate is about to expire (that is 30 days from the expiry date), iLO initiates certificate renewal automatically. As soon as iLO initiates certificate renewal, the certificate enrollment status will change to InProgress.

Certificate enrollment status will change to Success when the renewal is successful. For information on renewal status, see the Security Logs. You must reset iLO manually after successful renewal. The newly trusted certificate will be in use only after iLO reset.

Certificate enrollment status will change to Failed if the renewal fails. For more information on cause of failure and recommended actions, see the Security Logs.

Disabling enrollment service

Disabling enrollment service does not remove the certificate generated using the service. To remove the certificate, see Removing a TLS/SSL certificate.

When the service is disabled, iLO does not initiate renewal of the certificate automatically.

Prerequisites:

• iLOConfigPriv privilege

To disable Automatic Certificate Enrollment, perform PATCH on /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

PATCH /redfish/v1/Managers/1/SecurityService/AutomaticCertificateEnrollment

Viewing iLO TLS/SSL certificate

Webserver certificate whether self-signed, manually imported or issued automatically can be viewed by performing GET on /redfish/v1/managers/1/securityservice/httpscert/

GET redfish/v1/managers/1/securityservice/httpscert/?$select=X509CertificateInformation

Removing a TLS/SSL certificate

Use this feature to remove an SSL certificate and regenerate the iLO self-signed certificate.

You might want to remove a certificate for the following reasons:

• The certificate expired.
• The certificate contains invalid information.
• There are security concerns related to the certificate.
• An experienced support organization recommended that you remove the certificate.

Prerequisites:

• iLOConfigPriv privilege

DELETE /redfish/v1/managers/{item}/securityservice/httpscert/

TrustedModules (TPM)

Trusted Platform Modules and Trusted Modules are computer chips that securely store artifacts used to authenticate the platform. These artifacts can include passwords, certificates, or encryption keys. You can also use a TPM or TM to store platform measurements to make sure that the platform remains trustworthy.

On a supported system, ROM decodes the TPM or TM record and passes the configuration status to iLO.

GET /redfish/v1/Systems/1

Server management identities

This section provides technical detail concerning the HpeSecurityService resource type and its server management identities (DevID).

DevID is a standard (IEEE 802.1AR) to uniquely identify a server across networks. DevID is uniquely bound to a server that enables a server to prove its identity in various industry standards and protocols that authenticate, provision, and authorize communicating devices. HPE iLO supports factory provisioned server identity (iLO IDevID) and user defined server identity (iLO LDevID). HPE iLO also stores the system certificates (System IDevID and System IAK).

Following are the different server management identities described in this section:

• iLO IDevID
• iLO LDevID
• System IDevID certificate
• System IAK certificate
• Platform certificate

iLO IDevID

iLO can be provisioned with server identity in the factory. This factory provisioned server identity is called iLO IDevID. HPE servers can be securely on boarded into a customer network using the IDevID for 802.1X authentication. HPE iLO IDevID has life time validity and is immutable.

To instruct the HPE factory to provision a server with an IDevID, include either SKU P41905-B21 (if you do not have a TPM2.0 module) or P42104-B21 (if you have a TPM2.0 module) in your order.

iLO does not allow you to update or delete IDevID since it is immutable. You can view the iLO IDevID certificate using the RESTful API GET command toward /redfish/v1/Managers/{@managerId}/SecurityService/iLOIDevID/Certificates/{@certId}

iLO LDevID

iLO IDevID described in the previous paragraph can be supplemented by a user defined server identity, called iLO LDevID. iLO LDevID is unique in the administrative domain in which the server is used. HPE servers can be securely on boarded into a customer network using the iLO LDevID for 802.1X authentication. HPE iLO LDevID can be used on servers that do not have iLO IDevID. LDevID helps in facilitating the enrollment (authentication and authorization of credentials) by local network administrators. iLO allows to import, view, and delete LDevID outside the factory.

Importing an LDevID certificate

Follow these steps in sequence to import an iLO LDevID certificate:

• Generate a Certificate Signing Request (CSR) for iLO LDevID with a body containing the location where the signed certificate will have to be posted. Refer to the next example. A successful response contains the CSR as well as a link to the destination of the signed certificate in the CertificateCollection object.

  • iLO LDevID CSR generation
  • Body
  • Response (truncated)

  POST /redfish/v1/CertificateService/Actions/CertificateService.GenerateCSR

  NOTE

  Starting with version 1.60 and later, HPE iLO 6 is compliant with the IEEE 802.1AR standard that specifies Secure Device Identifiers (DevIDs).

  Refer to the next paragraph for detail concerning the IEEE 802.1AR compliant CSR format.

• Send this CSR to your favorite Certificate Authority to obtain back a signed certificate.

• Import the signed LDevID certificate into iLO. HPE iLO allows the import of LDevID certificates in PEM format using the RESTful API POST command with a body containing the CertificateType and CertificateString properties, as shown in the next example.

  NOTE

  Replace non ASCII characters like CRLF or CR with literally "\n" in the CertificateString property.

  Refer to the Installing certificate section for examples to achieve this task.

  • Import signed LDevID certificate
  • Body
  • Response

  POST /redfish/v1/Managers/1/SecurityService/iLOLDevID/Certificates/

  NOTE

  Before importing, iLO validates the input certificate with the following parameters:

  • The public key in the certificate matches the one generated with its corresponding CSR.
  • The signing and hashing algorithms used in the certificate are FIPS compliant.

iLO LDevID CSR format

As already mentioned, starting with version 1.60 and later, HPE iLO 6 is compliant with the IEEE 802.1AR standard.

The following table explains how the X509 Subject field attributes are used in iLO LDevID CSRs when iLO 6 firmware is 1.60 or above. Empty Example cells mean that value of the corresponding attribute is fixed and mentioned in the Value cell.

Acronyms are explained in the glossary.

The following table explains how the X509 Subject Alternative Name extension is formated when iLO 6 firmware is 1.60 or later.

Acronyms are explained in the glossary.

The following table explains how the X509 Subject Alternative Name extension is formated when iLO 6 firmware is 1.60 or later.

Viewing the imported LDevID certificate

To view the imported LDevID certificate, use the following RESTful API GET command toward /redfish/v1/Managers/{@managerId}/SecurityService/iLOLDevID/Certificates/{@certId}

Deleting the imported LDevID certificate

To delete the imported LDevID certificate, use the following RESTful API DELETE command toward /redfish/v1/Managers/{@managerId}/SecurityService/iLOLDevID/Certificates/{@certId}

Updating an LDevID certificate

You cannot update a LDevID certificate. To replace a certificate, you must delete the existing LDevID certificate and generate a new certificate. See Importing an LDevID certificate.

System IDevID certificate

HPE iLO can be provisioned with the server host identity, available for use by the operating system. This factory provisioned system identity is called System IDevID, whose corresponding private key is stored in TPM. System IDevID follows the TCG proposal for TPM2.0 implementation of an IDevID. You have to order a specific server SKU (P42104-B21) for obtaining System IDevID.

HPE iLO does not allow you to update or delete the certificate. You can only view the certificate using the RESTful API GET command toward /redfish/v1/Managers/{@managerId}/SecurityService/SystemIDevID/Certificates/{@certId}

System IAK certificate

HPE iLO can be provisioned with the System Initial Attestation Key (IAK) certificate in the factory. This is similar to System IDevID but used for TPM-based attestation. The corresponding private key is stored in TPM. System IAK follows the TCG proposal for TPM2.0 implementation of an IDevID. You have to order a specific server SKU (P42104-B21) for obtaining System IAK certificate.

HPE iLO does not allow you to update or delete the certificate. You can only view the certificate using the RESTful API GET command toward /redfish/v1/Managers/{@managerId}/SecurityService/SystemIAK/Certificates/{@certId}

Platform certificate

HPE iLO can be provisioned with the platform certificate which is an attribute certificate that functions as a signed manifest for the hardware chassis or configuration used to detect supply chain tampering. This certificate is TCG compliant. You have to order a specific server SKU (P42104-B21) for obtaining Platform certificate.

iLO does not allow you to update or delete the platform certificate. You can only view the certificate using the RESTful API GET command toward /redfish/v1/Managers/{@managerId}/SecurityService/PlatformCert/Certificates/{@certId}