Let's Encrypt rolls out free security certs for IP addresses Let's Encrypt, a certificate authority (CA) known for its free TLS/SSL certificates, has begun issuing digital certificates for IP addresses. It's not the first CA to do so. PositiveSSL, Sectigo, and GeoTrust all offer TLS/SSL certificates for use with IP addresses, at prices ranging from $40 to $90 or so annually. But Let's …
This post has been deleted by its author
the dents i've made in the office wall when trying to explain to developers & devops guys...
PLEASE don't hard code ip addresses in your scripts
no i can't give the new servers the same ip address as the old servers & run them in parallel while we migrate
No i'm not going to edit your scripts for you & no im NOT going to wait until you've had a training course before doing the migration
Give tham an isolated bit of network to play with. Then add a second DHCP server to it and let them figure it out.
Well yes that is one way; alternatively you tell them to fuck off and try to understand how networks, well, work.
No, hang on that won't work will it, said ‘expects’ will have the ear of the C-suite, so we have to be more creative; so you do exactly what they demand, no more, no less but do email any concerns about it to them, the company directors and a copy to your own personal (not company related) address.
Because if and when the project all goes tits up (or nipples North as a now, alas deceased college of mine referred to it as), have a defence. It doesn't have to be a perfect defence, but when they are looking for someone too blame and fire, any reasonable defence is better than none!
And yes, Im British so I’ve spelt defence with a ‘C’ rather than an ’S’; but I’d like to think that the vast majority of my fellow US based communards on here are bright enough to understand this and know what I mean!
I see the mistake you've made.
You've used your own head to make those dents in the office wall.
You need to use the dev guys' heads to make those dents. Go for the biggest one out of the group. Once the rest see what happens they'll fall in to line.
Follow me for more IT management by hand grenade tips.
Does anyone here work in construction?
Genuine question... do you get electricians who don't know what a plug is?
As, lets be honest, that's what this is. A devops person should understand the basics of this stuff.
Is it unique to our industry or are all industries full of numpties being dragged along by the ones who tut?
Depends on age of wiring. Only needed an electrician after 2005, when the building regulations changed.
However, you can still do your own ring circuits etc. just that you need an electrician to inspect and issue a certificate. I assume your solicitor did ask for an electrical certificate when you brought the house…
I've found large variance in skills in all types of IT jobs. It's not just devs who don't know how the systems work or sysadmins who don't understand the basics of development (not just how to write software themselves, but anything related to what a dev might need or ask for), but devs who don't know basics and sysadmins who don't know how to run their systems. Filtering out those people is an unending task that we're stuck with.
I doubt it's limited to tech either. At some point, people end up with a level of knowledge just because, if they lacked it, they would have failed sometime before now. That doesn't work for people who have less total experience in the field, where someone might have assumed that they showed promise and could pick something up. However, since tech changes, I've seen the same things with people who had skills that are no longer relevant but have tried to coast with those instead of learning something new, like the sysadmin who probably would do a pretty good job if sysadmining still mostly involved managing fleets of Windows 98 desktops, but couldn't manage a Linux server, nor a Windows server, nor a Mac OS anything, and wasn't too strong on a Windows 7 desktop (that was when I knew him). That part is possibly where tech and some other fields differ, as not all of them move as quickly.
Flag that one up early to the PM as a project risk. Then flag it as a security risk and let the resident hot head from security raise hell. Let the PM and security deal with it. Meanwhile go about the business of surfing El Reg while the Devs sweat bullets.
If, and only if, Devs come back with a story about a brain dead piece of hardware or software can't deal with hostnames, time to make bank in asking for shiny new kit to handle the upgrade process. Gold plate it. Go nuts.
Hopefully using the thick skulls of said developers and devoperatives and not your fist for this mural dentistry. ;)
It's the idea of abstraction that requires forcible cranial insertion. These dropkicks typically don't use virtual memory address when programming but symbolic abstractions (identifiers ~ names) for their programs' objects (variables, procedures etc); one would imagine that no great conceptual leap is required to understand that IP addresses (or indeed even hardware addresses) and server names bear the same relationship.
If what something does is only contingently related to how it does it (that is it could be implemented differently) at least one level of abstraction (typically indirection) is indicated.
In this particular context a naming service would be required which might be DNS but in some environments might be LDAP or NIS or heaven forbid NIS+ and I don't doubt quite a few more truly obscure ones. With the abstraction of the name service switch found in most *ixes you can also mix and match services. ;)
I don't suppose LE will be issuing wild card certs for IP addresses even if such things were possible..
I didn't realise we've worked with the same group of developers. The other trick they like to do is take the credentials you've given them for sending mail from one site, and reuse them across all the sites they build - even though you have explicitly told them not to do that.
And then the f***ing f***ers have the cheek to complain that all their sites break when you have to change the password on that one account - possibly because the devs have leaked it, or one of their servers has been compromised and is spewing spam.
You’ve missed the part whether the developers share the credentials in plain text over slack/teams/whatsapp/whatever with their team members and other teams who also need a credential even though the company has its own servers running privatebin.
A quick search for secret/password or similar in your companies messaging system can quickly make you want it to be Friday afternoon
Where I live the houses are mostly owned by a housing association. They've all been fitted with sophisticated wireless smoke detectors, three in each house and a button. When someone burns the toast half the smoke alarms in the street go off. I suspect they've all been set to the same house number.
I've found doing CompSci in college, and coding my fair share of boilerplate instant-legacy code in Java at the time has helped me in better handling various aspects of IT in my career - writing better PowerHell scripts being one example.
I can't help but shake the feeling most devs would benefit greatly from the inverse; working in IT for a year or two.
Picture this scenario.
You're deploying a client/server system that runs in the local network of a factory.
You start a client somewhere, and the server name does not resolve. This is because the factory does not have a network administrator, or if it does it's actually a monkey with "IT" sprayed over its fur, and the network configuration is screwed worse than [insert something inappropriate here].
Do you:
A) Abort the deployment, which will cause an entire production line to remain idle until the monkey comes back in two weeks' time (yes, of course it went on holiday the day before a major deployment)?
Or:
B) Try to fix their DNS, even though it's not your network and this means that the monkey will just point at you every time something goes wrong for the next 10 years?
Or:
C) Put the IP address in the startup script, and write down a recommendation to fix their DNS and then update the startup script with the server name, knowing full well that it's never going to happen?
Sometimes the lesser evil is all you can get.
There is a lot of "was" used in that article, so it's really quite unclear what, if any, of that system is still running.
However, going on the scant technical details in that article and obtained in a very quick search, which is all it deserves, these would appear to be ISP DNS filters. That means the answer to your original question is "technically yes but not really in practice", and if you don't already know how to bypass that then this won't help you.
> Entering theregister.com's IPv4 address (104.18.4.22) directly into the browser's address bar produces an error.
Yeah well...... 104.18.4.22 is not The Register, it is Cloudflare. A proxy which expects a hostname along with the naked IP. The error is specific to Cloudflare, not the innernet generally.
In the past I have done IP-only surfing. One specific reason is to test the server while a new IP/DNS entry propagates.
I have also run a flock of websites on one machine and IP with vhosting.
Neither the article nor the Let's Encrypt link give any realistic reasons for needing a cert for an IP address, so what is this actually about? What's the use case?
A cert proves that you own the resource, and enables encryption. But how do you prove that you own an IP address? The vast majority of users are just borrowing one from someone else who leased it. If I create a server somewhere, get a cert for the IP address, and then delete the server, there are probably going to be 5 days where I have a cert for somebody else's new server.
And you don't need a TLS certificate to enable encryption anyway.
Is this actually for sites which can't get a domain name because the name would be seized by a govt agency? Certificates for the dark web?
Well, for example, I was recently moving data with a temporary server, which I accessed by IP address because it wasn't going to stick around long enough to need a domain name attached to it. I encrypted my traffic with a self-signed certificate (actually a certificate signed by a separate CA which is also me, so not exactly what the phrase suggests, but the same general idea). Compared to getting one from LE, that is less convenient. I had to do manual work to get the cert installed properly, and mostly to bludgeon everything that interacted with it into not complaining about the CA they didn't know. That's fine because it was just me, but if someone else was doing this, a certificate from someone else would be better.
Or you might do this for something you wanted to access without a trusted DNS system, for example an authentication system or test page for a VPN. Or you're trying to keep a server under the radar or avoid announcing its ownership. With all of these cases, you could still use DNS to do it, with DNSSEC or custom records to deal with the untrustworthy DNS source problem. If someone had any of these use cases in mind, I would probably recommend that they use the DNS method. There are two reasons someone might choose otherwise. First, they might be doing something temporary and don't want to spend much time on their solution, and the DNS version could take longer. Second, I'm a programmer, so it's easier for me to say and implement something like "encrypt a structure with the verification data with a private key, store that in a TXT record, retrieve and verify it with an included public key in your software, have an automatic sync system to change that when you need to using your registrar's API [if they have one]" than for some people who aren't building a custom client and want to do something quickly with a normal browser.
A certificate does not prove that you own anything.
All a certificate provides is a method to negotiate what should hopefully be secure communications between the two systems. They do not guarantee ownership of the end point; they do not guarantee that the communications won't be intercepted along the way by some other party who also holds the certificate; they do not guarantee that either end won't record or transmit the information outside this connection. For some aspects of this we have some validation in place and we have certificates that, hopefully, are validated and in a chain of trust and therefore there is a certain amount of trust possible in these, but even these certificates can be leaked or sometimes abused to allow unauthorised certificates to be generated within an existing chain of trust.
As for a use case for these, how about your firewall administration interface? There's a very good chance a name won't be assigned to it and therefore an IP linked certificate is ideal for this kind of thing. A process somewhat let down by there being private IPv4 address ranges and these are the addresses that are more in need of such certificates. There are definitely use cases out there, where managing the names of devices is pretty pointless, and likely more for IPv6 addresses, and there are fewer use cases than for certificates linked to DNS names - more examples can be found in IoT or industrial automation where devices are connected by IP, not names. Which is probably why it's taken this long for this service to be created.
A certificate does not prove that you own anything.
When you request a certificate for a domain Let's Encrypt verifies that you control that domain. Specifically, it uses ACME to contact the domain and confirm that you have placed a secret on the endpoint. The intention is to establish "proof" of "ownership". If it didn't establish that, then I could just just get a certificate for my local bank and take all their money.
I have a fix IP address ... with a dozen domains hosted on it ... and if I put in the ip address direct I already get redirected to the default website ... OK the initial connect is insecure but it redirects to sites already in my LetsEncrypt folio of certificates. Does having a certificate for the ip address give me anything else other than stopping Firefox moaning if I add the https:// ? Without the domain name one can only get at the raw devices ...
Stopping Firefox from moaning (adding an exception) is bypassing the need for a certificate. So yes, having a certificate for the IP address gives you the actual benefit of having a certificate to verify the authenticity of the connection.
It's moot if you don't care, though. It's rather unlikely that you're going to be redirected to a fake server having that numeric IP address. (It would take a man-in-the-middle type adversary within your network to be able to pull that off successfully)
Another thing you can do, if any of those domains are yours, is simply add an A record to the DNS for it to one of them, that presumably has SSL certs. Then you can connect to https://servername.yourdomain.com:port (that's how I get around this)
"Another thing you can do, if any of those domains are yours, is simply add an A record to the DNS for it to one of them, that presumably has SSL certs. Then you can connect to https://servername.yourdomain.com:port (that's how I get around this)"
Which is exactly how things are set up at the moment, but having written the original post HAS answered the question posed and I will slip an IP certificate in the mix since it's not going to cost anything. Without LetsEncrypt I would be spending a lot of money on alternatives ...
Couple of minor points...
-- Although it might seem so the Internet isn't just websites hosting transactions
-- Having to manage innumerable, rapidly changing, certificates is going to lead to lapses and lapses tend to be security breaches that can be exploited
-- I thought that IPv6 was going to fix the problem with mutable IP addresses
DNS -- name lookup -- is useful and important but if its allowed to become preeminent, a cartel product, then it defeats the entire purpose of the Internet
I had a contiguous block of 8 IP adresses that came with my ISDN line with Demon Internet (yes, that long ago).
Ran a home lab - two mailservers, a fileserver, webserver, my home PC, etc, all in my flat and all accessible remotely (NATed through a firewall of course).
Had to request it, and give them a reason, but it didn't cost me a penny more than the basic account itself.
Them days are gone, sadly.
>if there is some way leverage this for covert data exfil
No, as it just merely permits the usage of CA-verified TLS without needing a domain.
You could previously use TLS just fine with IP addresses provided you used software that didn't disallow TLS to IP addresses and used self-signing, or disabled signature verification.
It would be pointless to try to configure a firewall to allow only TCP+TLS, as disallowing normal ICMP, TCP & UDP packets would break the network, as DNS couldn't work.
>Or maybe to create some type of alternative to TOR and I2P
It was never "TOR" - it's Tor.
Tor already uses TLS to IP addresses without domains, as it uses a different method to CA's to verify X.509 certificates.
A large increase in usage of TLS to IP addresses with a server name field set to the IP address, might eliminate such limited method of fingerprinting tor packets (although tor probably already mitigates that).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
