How to Configure HTTP Method on a Cisco Switch

The HTTP and HTTPS server on a Cisco switch is what powers the built-in web Device Manager and the REST interfaces that management tools talk to. It is off by default, and for good reason: an open HTTP server is a management-plane attack surface. This guide shows how to enable it correctly, lock it down with HTTPS and an access class, and verify it with real output from a Catalyst switch running IOS XE 17.18.

What the HTTP Server Actually Does

Two independent services live here: the plain HTTP server on TCP 80, and the secure HTTPS server on TCP 443. You almost always want HTTPS only in production. Both share the same authentication method and the same optional access class, so you configure authentication and access control once and it applies to whichever listener is enabled.

Enabling the HTTP Server

Turn on the server, point authentication at the local user database, and cap the concurrent sessions and timeouts so a stuck client cannot tie the box up:

Switch(config)# ip http server
Switch(config)# ip http authentication local
Switch(config)# ip http max-connections 4
Switch(config)# ip http timeout-policy idle 600 life 86400 requests 100

Verify it is running:

Switch# show running-config | include ip http
ip http server
ip http access-class ipv4 MGMT-HOSTS
ip http authentication local
ip http secure-server
ip http max-connections 4
ip http timeout-policy idle 600 life 86400 requests 100

Enabling HTTPS the Right Way

This is where the common guides go wrong. You do not manually point the switch at a trustpoint called TP-self-signed. When you enable the secure server, IOS XE generates a self-signed trustpoint automatically, with a random suffix, and binds it for you:

Switch(config)# ip http secure-server

That is the whole command. Now look at what the switch built:

Switch# show ip http server secure status
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite:  dhe-aes-cbc-sha2 dhe-aes-gcm-sha2
        ecdhe-rsa-aes-cbc-sha2 ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2
        tls13-aes128-gcm-sha256 tls13-aes256-gcm-sha384 tls13-chacha20-poly1305-sha256
HTTP secure server TLS version:  TLSv1.3 TLSv1.2
HTTP secure server trustpoint: TP-self-signed-2957430692
HTTP secure server ECDHE curve: secp256r1

The trustpoint is TP-self-signed-2957430692 - the switch named it itself. You only issue ip http secure-trustpoint <name> when you have a proper CA-signed certificate and want the switch to present that instead of the self-signed one. Typing ip http secure-trustpoint TP-self-signed by hand, as many older guides show, points at a trustpoint that does not exist and breaks HTTPS.

Restricting Who Can Connect

An open management server should never listen to the whole network. Bind an access class so only your management subnet can reach it:

Switch(config)# ip access-list standard MGMT-HOSTS
Switch(config-std-nacl)# permit 10.10.99.0 0.0.0.255
Switch(config-std-nacl)# exit
Switch(config)# ip http access-class ipv4 MGMT-HOSTS

Confirm the full server state, including the access class and the ports actually bound:

Switch# show ip http server status
HTTP server status: Enabled
HTTP server port: 80
HTTP server authentication method: local
HTTP server IPv4 access class: MGMT-HOSTS
Maximum number of concurrent server connections allowed: 4
Server idle time-out: 600 seconds
Server life time-out: 86400 seconds
Maximum number of requests allowed on a connection: 100
HTTP secure server capability: Present
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server TLS version:  TLSv1.3 TLSv1.2
HTTP secure server trustpoint: TP-self-signed-2957430692

The HTTP server IPv4 access class: MGMT-HOSTS line is your proof the restriction is live. Without it, that field reads None and anything routable to the switch can hit the login page.

Authentication Options

Local authentication (against username accounts on the box) is fine for a lab or a small estate. For anything larger, point it at AAA so the switch validates web logins against RADIUS or TACACS+:

Switch(config)# aaa new-model
Switch(config)# aaa authentication login default group tacacs+ local
Switch(config)# ip http authentication aaa

The trailing local in the method list matters: if the TACACS+ server is unreachable, the switch falls back to local accounts instead of locking you out of the web interface.

Troubleshooting

If you cannot reach the web interface, work through it in order. Confirm the server is enabled and on the port you expect with show ip http server status. Confirm your source address is permitted by the access class - the single most common cause of a refused connection once the server is up. For HTTPS specifically, confirm the trustpoint field shows a real trustpoint name; if it is blank, the self-signed certificate did not generate, and toggling no ip http secure-server then ip http secure-server regenerates it. Finally, confirm authentication: a login that fails silently usually means the method list points at an unreachable AAA server with no local fallback.

Key Takeaways

• Enable HTTPS with just ip http secure-server; the switch generates and binds its own self-signed trustpoint (here TP-self-signed-2957430692).
• Only use ip http secure-trustpoint when you are installing a real CA-signed certificate - never point it at a hand-typed TP-self-signed name.
• Bind ip http access-class to a management subnet; verify it shows in show ip http server status.
• Prefer HTTPS over HTTP, and end AAA method lists with local so an unreachable server does not lock you out.

More Cisco admin how-tos: How to Import Files to Cisco Router.