Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Step CA as an ACME server? #55

Closed
budulinek opened this issue Aug 7, 2022 · 9 comments
Closed

Use Step CA as an ACME server? #55

budulinek opened this issue Aug 7, 2022 · 9 comments

Comments

@budulinek
Copy link

OK, I know you have invested a lot into Boulder. But still, I would like to start the discussion...

Couple of hours ago I did my very first installation of Step CA as an ACME server. It was actually much easier than expected (follow this guide ).

So now I have both Boulder (LabCA) and Step CA, each within its own LXC. And a bunch of ACME clients to test them. Some quick comparison of Step CA over Boulder:

  • Step CA has no limits (quite handy if you are testing things), while Boulder complains that "Error creating new order :: too many certificates (2) already issued for this exact set of domains in the last 3 hours..."
  • Step CA can issue certs for an IP (quite handy for internal servers...), compared to Boulder throwing an error "NewOrder request included invalid non-DNS type identifier: type "ip""
  • Step CA is a full-fledged certificate authority (incl. ACME server). You can either issue certs manually (bypass domain-authorization), or use ACME protocol. Boulder is "just" an ACME server. If you want a cert from Boulder, you have to use ACME.
  • Step CA is distributed both as a dockerfile and regular package (useful if you can not or does not want to use Docker). Boulder only comes as a dockerfile.
@hakwerk
Copy link
Owner

hakwerk commented Aug 20, 2022

When I started this project in 2018, Step CA ACME did not exist yet. It's only become available about a year ago or so.

Thanks for the comparison, I haven't come around myself to trying it out. Sounds like you should stick to Step CA 😄

@budulinek
Copy link
Author

budulinek commented Aug 21, 2022

Boulder sucks but LabCA is great... Most of my ACME clients are conneted to LabCA, only when Boulder fails to do the job, I redirect the client to Step CA. So at the moment I have both LabCA and Step CA running.
Also:

  • Step CA does not validate against CAA records (see . explanation). Boulder does.

Having LabCA with Step CA would be great. I looked at your code but replacing Boulder with Step CA is beyond my skills (I know nothing about Go, very little about dockers).

@budulinek
Copy link
Author

I did a bit of research on Step CA. You may find it useful in case you are considering Step CA.

The good news:

  • There is a Go wrapper for Step CA (here and here ). And a CLI client.
  • Step CA stores data about certs, accounts, etc. in a database. You can choose your database (default is Badger DB - never heard about it...). See here .
  • There is also a sample Go script for accessing the Badger DB here .

The bad news:

  • Badger (the default DB) only allows one process accessing the DB. So you need to stop Step CA (or make the copy of the DB) if you want to read the data...
  • At the moment, Step CA uses NoSQL storage schema (key -> value, probably stored in raw bytes...). Exploring the data may be difficult.
  • Smallstep promised to swith to standard SQL schema ( here ) after several requests for more reporting capabilities from their users (see here, here, and a discussion). Step CA users knew about you :-) . They asked smallstep for "web interface similar to that provided by labca" already 2 years ago (here) ... But so far there is neither the webinterface for Step CA (and there never will be), nor the promised SQL storage backend.
  • Instead, smallstep is pushing users towards their hosted Certificate Manager service. Acording to this post, while working on the commercial Certificate Manager, they have already "written a sql backend for the db which will be merged into the open source soon". That was in March 2021. The promised merge to open source did not (yet) materialize.

If you plan to add new features to LabCA, it makes little sense to stick with Boulder. For example, if you want to renew / replace Root and Issuer CA certificates with Boulder, you need to do that manually with openssl (= danger of misconfiguration). With Step CA, (re)placing root is easy with one command (step ca init). On the other side, the missing SQL backend is a dealbreaker at the moment.... So my humble suggestion would be: wait with new LabCA features. Switch to Step CA once they merge their SQL backend into open source?

@hakwerk
Copy link
Owner

hakwerk commented Sep 7, 2022

Actually, it turns out the current MySQL database is already quite usable! I have made a standalone version of the LabCA GUI that can work with the step-ca database to show the ACME information. The .deb is on the latest release page. More info here.

I haven't bothered with BadgerDB, the limitation of only one process accessing it at the same time is just horrible.

I quickly tried integrating the revocation of certificates, but automating that is however not so easy. On the command line you either manually need to select the provisioner and provide the password, or provide a token for which you also need to select the provisioner and provide the password? Looking at the API documentation I haven't solved that issue. But I guess if you have this GUI you can easily lookup the serial of the certificate that you want to revoke and then do it with the step cli.

@budulinek
Copy link
Author

Thanks a lot!

I tried to run the standalone version and got an error:

# labca-gui -config stepca.json -port 80 -init
panic: fatal error templates: 'templates: filepath.Walk error: lstat ./templates: no such file or directory'

goroutine 1 [running]:
main.init.0()
        /home/runner/work/labca/labca/gui/main.go:2825 +0xcfc

Some hard-coded path in the binary?

@hakwerk
Copy link
Owner

hakwerk commented Sep 25, 2022

Hmm, there was a small bug in determining if the embedded templates should be used or the templates from a directory. Should be fixed now in the latest release (v22.09.1).
Thanks for trying it out!

@hakwerk hakwerk closed this as completed Oct 28, 2022
@budulinek
Copy link
Author

budulinek commented Nov 18, 2022

Hi, just want to say that it works! Thanks a lot!

I have some minor issues with web server paths:

certificate details

2022/11/18 22:26:01 errorHandler: err=NotFoundHandler for: GET /certificates/static/css/bootstrap.min.css
2022/11/18 22:26:01 errorHandler: err=NotFoundHandler for: GET /certificates/static/css/metisMenu.min.css
2022/11/18 22:26:01 errorHandler: err=NotFoundHandler for: GET /certificates/static/css/sb-admin-2.min.css
2022/11/18 22:26:01 errorHandler: err=NotFoundHandler for: GET /certificates/static/css/font-awesome.min.css
...

and account details

2022/11/18 22:28:31 errorHandler: err=NotFoundHandler for: GET /accounts/static/css/bootstrap.min.css
2022/11/18 22:28:31 errorHandler: err=NotFoundHandler for: GET /accounts/static/css/metisMenu.min.css
2022/11/18 22:28:31 errorHandler: err=NotFoundHandler for: GET /accounts/static/css/sb-admin-2.min.css
...

same with authz, orders and challenges details.

webpage loads but without CSS styles and stuff.

@budulinek
Copy link
Author

Run as systemd service, works for me (please double check):

$ sudo labca-gui -config /etc/labca/labca.json -port 3000 -init
$ sudo useradd --system --home /etc/labca --shell /bin/false labca
$ sudo chown -R labca:labca /etc/labca
$ sudo nano /etc/systemd/system/labca.service
[Unit]
Description=LabCA service
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=30
StartLimitBurst=3

[Service]
Type=simple
User=labca
Group=labca
WorkingDirectory=/etc/labca
ExecStart=/usr/bin/labca-gui -config /etc/labca/labca.json
ExecReload=/bin/kill --signal HUP $MAINPID
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitInterval=30
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

$ sudo systemctl daemon-reload
$ systemctl enable --now labca

@skull-squadron
Copy link

For posterity and an update, step-ca is a FOSS-washing commercial project where useful features are locked away behind a paywall deliberately.

Comparison with Smallstep's commercial product
step-ca is optimized for a two-tier PKI serving common DevOps use cases.

As you design your PKI, if you need any of the following, [consider our commerical CA](http://smallstep.com/):

Multiple certificate authorities
Active revocation (CRL, OSCP)
Turnkey high-volume, high availability CA
An API for seamless IaC management of your PKI
Integrated support for SCEP & NDES, for migrating from legacy Active Directory Certificate Services deployments
Device identity — cross-platform device inventory and attestation using Secure Enclave & TPM 2.0
Highly automated PKI — managed certificate renewal, monitoring, TPM-based attested enrollment
Seamless client deployments of EAP-TLS Wi-Fi, VPN, SSH, and browser certificates
Jamf, Intune, or other MDM for root distribution and client enrollment
Web Admin UI — history, issuance, and metrics
ACME External Account Binding (EAB)
Deep integration with an identity provider
Fine-grained, role-based access control
FIPS-compliant software
HSM-bound private keys

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants