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.
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.
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):
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.
Confidentiality - A (passive) adversary cannot read the content of the connection (the plaintext). This is what we usually mean when we say "encryption".
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 .
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.