Cradlepoint Router

I am trying to replace the Self-Signed Certificate that came with my Cradlepoint Routers for Remote Management using its embedded server. The router does not have a DNS entry or a Domain Name. It only uses a Public Static IP Address. The routers do support requiring only https access. However, all modern browsers refuse connections to Self-Signed certificates. This forces an unencrypted connection thereby causing its very own vulnerability.

I need to get legitimate verifiable certificates for these devices. Any help would be most appreciated.

Let's Encrypt (currently) only issues certificates for hostnames and not for IP addresses. This may change in the future, but there is no roadmap for this feature. So it might be many years.


Nonsense. They warn about such connections, of course, but they allow you to bypass the warning and connect.

There are CAs who will issue certs for IP addresses (I think ZeroSSL may be one), but they're relatively few and far between, and AFAIK, they won't do it for free. Another possibility would be to issue certs from an internal CA--then you just need to trust that CA's cert on whatever client device(s) you'd be using to manage the routers in question.

1 Like

Try putting it behind a proxy.

[note: "behind" is not a literal term - just a logical location of sort]


That's true that they give you the option to bypass the warning. But if you look closely Firefox, Chrome, Brave, etc all then establish an unencrypted connection when you do.

That's NOT true.


Again, nonsense--where are you coming up with these ideas? Here's what happens when you visit a site with a self-signed cert:

Notice the part where it says "Connection Encrypted" and then lists the cipher, followed by "the page you are viewing was encrypted before being transmitted over the Internet."


The browser will however show something like this, so I do understand @pwharton's confusion about this.


I also noted that in different languages this messages is sometimes poorly translated. Especially the difference between "unsecured" and "unencrypted" is hard to grasp for users I guess. At least it's easy to misunderstand the message.

To add some more theoretical juice why a connection can be both insecure but encrypted:

TLS has three security goals (together they form what we call a secure connection):

  1. Authentication - ensures that you're connected with the intended recipient (in https that means with the FQDN stated in the URL). This is what the certificate is for.
  2. Confidentiality - A (passive) adversary cannot read the content of the connection (the plaintext). This is what we usually mean when we say "encryption".
  3. Integrity - An (active) adversary cannot modify the content of the connection (undetected).

With a self-signed certificate (or any other certificate warning), authenticity may be broken. When authenticity is broken, you technically still have the other two goals, but they may have become useless: Because you have no authentication, you may actually be talking to the adversary directly. You still have a confidential conversation with the adversary though :grinning:.


If he’s administering enterprise gear (which is what Cradlepoint makes and sells), I’d expect him to be a bit more savvy than your average user.


Nummer378, Thanks for explaining my misunderstanding.

It seems somewhat counterproductive for the various web browsers to report "Connection not secure" when it actually still is. That's what was confusing me.

CP Router 1

The subtle distinction is what @Nummer378 was trying to explain. "Secure" is a somewhat nebulous term. You can have an encrypted conversation and still not be "secure" according to the browser because the browser is unable to validate the authenticity of the certificate that encrypted the conversation. But you being the admin of the device presenting the certificate allows you to verify the authenticity of the certificate in a way the browser can't. So creating a security exception is perfectly acceptable.

It should also be noted that the UX for this particular area of web browsers is in a constant state of flux as the vendors try and find the right balance between too much technical jargon that users will ignore and too simplified to be useful all while adjusting to the ever changing landscape of web security standards and practices. So don't feel bad that you find it confusing. At least you care enough to ask which is more than a whole lot of folks.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.