Mass registration on a single domain from a router vendor


#1

Hi,

I’m the CEO of Viprinet. We are a manufacturer of VPN Routers. Until now, we are shipping our routers with self-signed HTTPS certificates. Let’s encrypt would enable us and our customers to be safer. What we would like to do is that every of our router after getting configured by the customer would request a TLS certificate for SERIALNUMMER.ourdomain.tld. Dyndns-like, the router would update it’s IP with our DNS, and the customer therefore then would be able to always reach his router securely at https://SERIALNUMBER.ourdomain.tld.
(In addition we would support the user using his own domain instead, but by default we’d base this on the device serial number + ourdomain.tld).

The problem now is the current rate-limit limitation of 5 certificates per domain. If we ship this feature, there obviously over time would be hundreds to thousands of certificates.

We really think that Let’s Encrypt could be a nice way to make the configuration interfaces of routers safer by default, which would be a huge step forward for the Internet as a whole - after all, it’s routers that are attacked by all sorts of black hat organizations.

So, is there any way to get the limit lifted for a specific domain, and where could we request this?


Automization for company used guest portal
#2

I would suggest waiting until the beta is over. Another possibility could be becoming a sponsor.


#3

One option would be to get your domain added to the public suffix list - if you’re using a dedicated domain for this purpose, which is probably a good idea anyway. This would mean that the rate limits apply separately for each serialnumber.example.com subdomain. It also has the added benefit that your domain could not set cookies for all of your devices if someone accesses it directly.

You can do so by opening a pull request at https://github.com/publicsuffix/list.

Just out of curiosity, and since I’m not familiar with your product: How would you solve the ACME challenge? Are your products always reachable via WAN so that you could host the challenge files on port 80 (or 443 for tls-sni-01)?


#4

I already considered becoming a sponsor - but would that change anything really? I would expect sponsorship and policy decisions not to be related.


#5

@scamp You do realise that every issued Let’s Encrypt certificate is published on crt.sh ánd on multiple Certificate Transparency logs? I don’t know if your issued routers should be publicly known?


#6

Yeah, we have a dedicated domain for this purpose - “router.management” (geez, don’t you just have to “love” these fancy new TLDs…?). Thanks for the hint, adding that to the public suffix list indeed sounds like a plan.

Our routers typically are reachable from the Internet, as they are … Internet routers :wink: - so the ACME challange typically won’t be a problem. There are circumstances where the routers might be inside some Intranet and not allowed to talk to the public Internet at all. In this case the user will have to install their cert manually, like they had to today.


#7

Security by obscurity is nothing you should bet on for a router on the public Internet. And you can find those devices using Shodan anyway. And if you would like to keep your router invisble, you’d just uncheck the Let’s Encrypt option inside the Installer…


#8

That sounds like it should work. So your general workflow would be something like:

  1. Push the router’s WAN address to your DNS so the A record for serialnumber.router.management gets set.
  2. Spawn a publicly-available web server on port 80 or 443 (which you probably already have for the management UI) and serve the challenge files/SNI challenge.
  3. Let your ACME client do its magic and install the resulting certificate.
  4. Repeat steps 2 and 3 automatically every 2-3 months.

Sounds like a nice use-case for Let’s Encrypt! :ok_hand:


Public beta rate limits
#9

@scamp: We’re working on a rate limit override request form; it’s just a little slow right now around the holidays. Expect an announcement and instructions in early January, and it’ll be exactly what you need to accommodate all your devices.


Rate limit cert per domain
How to deal with rate limits for a bunch of internal servers behind a corporate IP?
Too many certificates already issued for: startdedicated.de
Public beta rate limits
DynDns/No-IP ("Managed DNS") support
#10

Yep, that’s exactly the plan.

I’ve added a pull request for the public suffix list. Any clue on how often this is fetched by Let’s encrypt?


#11

Usually a couple of weeks. You can follow the changelog on https://letsencrypt.status.io/, it’s usually mentioned when a new version is deployed.


#12

Just FYI, the rate limit override form will be the faster route than adding to the PSL. It really is coming.


#13

Just checking as not everyone is familiar with the ‘open’ nature of Let’s Encrypt :wink:


#14

Nice, that’s good news, thanks. We’ll use the time for beta-testing our integration feature with the 5 tries we have :wink:

Thank you very much for this great job you are doing for the community.


#15

pfg still has a point that the management domain should be on the PSL for cross-domain cookie security reasons. Let’s see which of the two ways turns out to be the quicker one :slight_smile:


#16

You can do initial testing with the staging (test) server … it hasn’t got the same limits :wink:


#17

Just curious: What exactly is the benefit of HTTPS here?


#18

The same for any site I’d have thought - confidentiality, identity and integrity.
If I’m making changes on a router or similar device, I want to be able to log in using a secure method HTTPS / SSH, so that all communication is encrypted between the two (i.e the passed data is confidential) the identity of the device is confirmed, and the integrity of the system is maintained.


#19

Yeah, but that’s a totally different attack vector. If routers are under attack from the Internet, HTTPS actually increases the attack surface because it is massively more complex code. It doesn’t prevent anyone from connecting.

The major attack vector in the router business (I assume this is SOHO or private customers) has never been that passwords were leaked over unencrypted connections. “All sorts of blackhat organizations” that turn your router into a botnet or a Bitcoin miner usually don’t have MITM capability before they successfully breach the router.


#20

Encrypting internal network traffic is a good mechanism of defense in depth (Just look up “SSL added and removed here” if you’re curious about why :smile:).

Agreed, in a typical setup, it’s game over once the attacker is in a position to MitM LAN traffic, but if you already have strict firewall rules, VLAN segmentation and what not, it’s definitely a step worth taking.

Sure, (open|boring|libre)ssl might introduce a whole new vector, but despite heartbleed and friends, the number of (realistically exploitable) RCEs or similar vulnerabilities that were found is quite low.