Configuring Secured (HTTPS) Web and REST Access
By default, the device allows remote management (client) to the device's Web and REST interfaces through both HTTP and HTTPS. However, you can enforce secure (HTTPS) access so that the device allows only HTTPS requests.
By default, servers using TLS provide one-way authentication. The client is certain that the identity of the server (i.e., device) is authentic.
When an organizational Public Key Infrastructure (PKI) is used, two-way authentication (mutual TLS authentication or mTLS) may be desired; both client and server (i.e., device) are authenticated using X.509 certificates. This is achieved by installing a client certificate on the client side (e.g., management computer, web browser, or REST-management tool) and uploading the Certification Authority's (CA) root certificate to the device's Trusted Root Certificates table (certificate root store). The Trusted Root Certificate file may contain more than one CA certificate (combined using a text editor).
The device’s REST-based management interface supports mTLS that also conditions access based on the certificate’s subject name—Subject Alternative Name (SAN) or Common Name (CN). When a user attempts to connect to the REST interface, the device verifies whether the subject name in the client’s certificate matches the 'TLS Subject Name' parameter value configured for any user in the Local Users table. If a match is found, the client is automatically authenticated, without needing to enter a username or password. The authenticated client is granted the user permission level associated with the corresponding user in the Local Users table.
When a user attempts to connect to the device's secured Web or REST interface:
|
■
|
If the user has a client certificate from a CA that is listed in the device's Trusted Root Certificate store, the device accepts the connection and prompts the user for the login password. |
|
■
|
If both the client certificate and CA certificate are in the Trusted Root Certificate store, the user is not prompted for a password. This provides a single sign-on (SSO) experience; authentication is performed only using the X.509 digital signature. |
|
■
|
If the user's client certificate isn't from a listed CA or doesn't have a client certificate, the device rejects connection. |
|
●
|
For secure management through the device's default management network interface (i.e., OAMP Application Type in the IP Interfaces table), the device uses the default TLS Context (Index #0 and named "default"). However, for secure Web- and REST-based management using additional management interfaces configured in the Web Interfaces table (see Configuring Web Interfaces), you can use any TLS Context. |
|
●
|
The 'Secured Web Connection (HTTPS)' parameter (mentioned below) is applicable to both Web- and REST-based management. |
You can enforce HTTPS access to the Web and REST interfaces through the default management IP interface (#0) by configuring either a global parameter or the Web Interfaces table. However, using the Web Interfaces table is recommended, as it provides greater flexibility. In addition to configuring the Web Interface for the default IP interface, the table allows you to create additional management interfaces and offers enhanced functionality.
|
➢
|
To configure HTTPS for Web and REST using global parameter: |
|
1.
|
Open the Web Settings page (Setup menu > Administration tab > Web & CLI folder > Web Settings), and then do the following. |
|
2.
|
From the 'Secured Web Connection (HTTPS)' drop-down list, select HTTPS Only: |
The following procedure describes how to configure HTTPS and mTLS for accessing the Web and REST interfaces.
|
➢
|
To configure HTTPS and mTLS for Web and REST: |
|
1.
|
(mTLS) Add client TLS certificates to your third-party REST management tool or web browser. For examples, see the following sections: |
|
2.
|
Open the Web Interfaces table (see Configuring Web Interfaces), and then configure the default Web Interface which uses the default IP network interface (#0) or configure a new Web Interface: |
|
a.
|
From the 'TLS Context Name' drop-down list, select a TLS Context in the TLS Contexts table. |
|
b.
|
(mTLS) From the 'Require Client Certificates' drop-down list, select Yes. |
|
c.
|
From the 'HTTPS Only' drop-down list, select HTTPS only. |
|
3.
|
(mTLS) Import the client's certificate file that was issued by the CA into the device's Trusted Root Certificates store: |
|
b.
|
Select the required TLS Context, and then click the Trusted Root Certificates link located below the table; the Trusted Root Certificates table appears. |
|
c.
|
Click Import, and then select the certificate file to import. |
|
4.
|
(mTLS for REST) To use the TLS subject name as a matching criteria between the client's certificate and a user in the Local Users table: |
|
b.
|
For the required user, configure the 'TLS Subject Name' parameter with the Subject Alternative Name or Common Name of the client's certificate. |
The example below shows the configured 'TLS Subject Name' as "rest_usr1":
The TLS subject name can be found in the Common Name (CN) or Subject Alternative Name fields of the client's certificate. Below shows "rest_usr1" in the Subject Alternative Name field:
|
●
|
The value of the 'TLS Subject Name' parameter for each user in the Local Users table must be unique. |
|
●
|
If you configure the 'TLS Subject Name' parameter, password configuration for the user is not mandatory. |
|
5.
|
Restart the device with a save-to-flash for your settings to take effect. |
|
●
|
Installing a client certificate on your computer is beyond the scope of this document. For more information, refer to your operating system documentation and consult with your security administrator. |
|
●
|
You can also upload the root certificate using the device's Auto-Update mechanism (see the [HTTPSRootFileName] parameter). |