Router manufacturers do not know what IP address their device will be assigned and therefore should not be able to register a TLS certificate for a router. However, some routers have HTTPS web-interfaces which do not trigger un-trusted certificate warnings when accessed.

How do router manufacturers achieve this?

  • Can you elaborate? Do you access these routers by IP address or by some novelty domain name such as 'home.router'?
    – Owen
    Commented Nov 9, 2017 at 3:18
  • 2
    "However, some routers have HTTPS web-interfaces which do not trigger un-trusted certificate warnings when accessed." - please show proof that these are really HTTPS and not plain HTTP interfaces you are talking about and that no browser issues certificates warnings at first access to the administrator page and without having vendor specific software installed. Commented Nov 9, 2017 at 5:56
  • 2
    Downvote because I doubt the initial claim of "... some routers have HTTPS web-interfaces which do not trigger un-trusted certificate warnings when accessed." and no proof is given. And, the accepted answer simply assumes that this claim is wrong too (i.e. access is HTTP not HTTPS) which makes me wonder how the OP keeps the claim in his question but is still accepting the answer as valid. Commented Nov 9, 2017 at 8:16
  • I haven't been able to confirm this on any routers I currently own, so you are probably correct. I'm not going to alter the question as that will just make the answers confusing and I think they do currently contain a lot of useful information.
    – andypea
    Commented Dec 6, 2017 at 22:06

3 Answers 3


Sadly most of them do not use https at all.

If no https is used no certificate check needs to be done. This is actually more insecure than having TLS with manually verified certificates, but I guess the vendors try to avoid scaring people and getting support backlash.

In the future when Browser will alert form submissions, this might change.

BTW, the actual problem is not the changing IP address, as most routers make themselves known under a local constant name. The actual problem is that the manufacturers have a hard time actually distributing a certificate for such a name in a way that malicious owners cannot retrieve the secret key. (Would require a HSM/TPM Protection)

  • "In the future when Browser will alert form submissions": I cannot tell for other browsers but Firefox already does this for authentication forms sent over insecure channels. Commented Nov 9, 2017 at 12:54
  • BTW, just to give some perspective. On a AVM Fritz Box with recent firmware it will generate a (untrusted) self-signed certificate (with the SAN=fritz.box entry). The admin GUI will print the fingerprint of this certificate (so you can verify it once). It also allows you to upload a user created key+cert. However it does not enforce or promote https logins.
    – eckes
    Commented Nov 10, 2017 at 6:07

The other answer is not completely right, hence I‘ll try and fix that.

There are two different types of web interfaces for routers: The internal and the external web interface.

While the external should be disabled for many reasons, the internal one does not need https to be deployed: as you are accessing the router from your LAN (let‘s just assume, CRACK might be fixed some day and WiFi is considered secure again), a MITM can only operate locally, which is not a big threat in most consumer cases.

Yet, generally it would be desirable to have https on COTS routers. This poses significant problems. While the IP itself would not be a huge problem as the actual IP is only checked when accessing directly via IP (as the IP is taken to be the domain), there is another problem: most SOHO routers either have no DNS zone for the devices or they can be configured.

Even if all routers of one model were to be configured with a not-changeable local domain name like „routerxy.local“, .local is a domain no CA would ever create a certificate for. This is the point the other answers misses. It’s not the storage of the certificate and key that is the deal breaker (it is one as well though, but could be mitigated with an HSM), it is the local domain and how CAs work.

There would be a way to mitigate this problem as well:

Maker x can create routery.x.tld and obtain a certificate for that - and distribute that in the HSM of every box they ship. If this gets leaked (by a vulnerability in the HSM, for example - they are now in the hands of the potential attacker), you are in huge trouble all over again.

Additionally, most CAs might revoke the certificate when they see abuse like that (as the entity the certificate is for is not the one using it)

All in all: there are technical difficulties that hinder usability (we do not want certificate warnings on our COTS router) and there is little benefit from using TLS on a connection that is merely within the LAN.

  • You always need https, CRACK was only one of the many weaknesses in WLAN.
    – eckes
    Commented Nov 9, 2017 at 6:15
  • I'll agree with smoke that a home router doesn't need https for initial setup (WiFi is off, only 1 cable is plugged in to the router and the admin's computer is on the other side of that cable). However once that router is in service and other computers are on the network, https is a must-have.
    – Owen
    Commented Nov 9, 2017 at 6:30
  • In a SOHO-environment, one should be fine w/o, as the threat model to be defending against is very limited in power; direct access to the network (and thus possession of the well chosen authentication method's secret) would be required
    – Tobi Nary
    Commented Nov 9, 2017 at 7:01

For HTTPS certificate, IP address don't matter, what matters is the DNS domain name that the device is assigned to. As long as the device is provisioned with a certificate and private key matching the DNS name that the router is assigned, then it can serve HTTPS for that domain name.

Since routers generally also acts as the DNS for the network it's serving, it's capable of adding any DNS name to the network. So all that's left is obtaining a publicly trusted certificate for that domain name.

Publicly trusted CA are restricted from issuing public certificates for DNS names that aren't registered in the public DNS system. According to my search, a number of sites claims to have some ASUS routers that have automatic HTTPS administration page on a domain name that looks like https://router.asus.com:8443, which is a publicly registered DNS address that belongs to the router manufacturers. The router manufacturers, ASUS in this case, can obtain a valid, publicly trusted certificate for that domain name as they own the asus.com domain name.

All that's needed now is for the router manufacturer to include the private key for the publicly trusted certificate in the devices they sell. This suggest that, when using the default certificate, a sufficiently advanced attacker may be able to extract the private key from the device to spoof the router admin page. Hopefully this shouldn't be straightforward as the router should not have allowed its admin domain name to be hijacked by other users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .