hakwerk / labca

A private Certificate Authority for internal (lab) use, based on the open source ACME Automated Certificate Management Environment implementation from Let's Encrypt (tm).
https://lab-ca.net
Other
375 stars 39 forks source link

[DOCS] Probable improvement of the docs on probable errors with a specific use case #117

Closed francescocaponio closed 8 months ago

francescocaponio commented 8 months ago

Not really an issue, but I had some troubles in debugging it before solving it.

Maybe this could be of help to other people. Could be added to the README.md in the common error messages section.

After you solved the #114, I started using it quite much for our internal development environment. We use docker containers to run separate development environments like gitpod or coder, and we use nginx proxy manager to manage the open ports of the containers with ssl (it automatically runs certbot pointing to labca to renew ssl certificates).

In order to allow developers to create their own shortcuts to specific ports, I created on the dns a wildcard record pointing to the development machine dev.lan, so they can create app1.dev.lan without the need to access to the DNS.

What I noticed is that Boulder woud stop me to create certificates after two successful certificates created for that machine, even if they are for different services. I hit the rate limit page of LabCA, and then I went to find the rate limits rules of the boulder container:

root@6e2e71548983:/opt/boulder# cat labca/rate-limit-policies.yml
# See cmd/shell.go for definitions of these rate limits.
certificatesPerName:
  window: 2160h
  threshold: 2
  overrides:
    ratelimit.me: 1
    lim.it: 0
    # Hostnames used by the letsencrypt client integration test.
    le.wtf: 10000
    le1.wtf: 10000
    le2.wtf: 10000
    le3.wtf: 10000
    nginx.wtf: 10000
    good-caa-reserved.com: 10000
    bad-caa-reserved.com: 10000
    ecdsa.le.wtf: 10000
    must-staple.le.wtf: 10000
    <my internal TLDs>: 10000

    ...

What I did to solve this problem was firstly to add the server name and domain dev.lan of the development machine to the rate limit policies file rate-limit-policies.yml, restart the boulder container and it started working. After that I thought that LabCA would add it automatically if added to the lockdown list, so I did it and restarted the container, solving my problem.

I hope it is a solution that will not damage any other part of the software stack, but it really solved my problem. Not sure if this is a standard use case, but I'm happy about it.

francescocaponio commented 8 months ago

Thanks, hope it could help other people too.

Doing so will not trigger any unwanted behaviour of boulder?

hakwerk commented 8 months ago

Thank you for the suggestion! Hopefully it is helpful for others indeed.

No it should be totally fine and not break anything else.