Certificate Revocation List

[Hardcorian]

Hello,

I installed and configured a Linux intermediate CA from a Windows Root CA, and working perfectly thanks to your documentation. It is a CentOS 7 version 1708.

When I revoke actively a certificate, I am not able to find the CRL or place where the revoked certificates are listed.

The goal of this is to have the revoked certificates by the Linux intCA in the same CRL as the Windows intCA, to work with only a unified CRL. In fact, in the Linux intCA certificate, I see that the CRL distribution point is the same as the Windows intCA.

Thanks so much.

[Hardcorian]

Hello,

Do you know any way to insert a CRL Distribution Point in the ACME generated certificates? With this would be enough for me.

Thanks!

[dopey]

Hey, apologies for the radio silence. We've been heads down for a little while and have let a few issues get away from us.

Unfortunately CRL and OCSP are, as yet, unimplemented in the CA. Even in so much as just adding the right extension to a newly minted cert. However, CRL and OCSP are on our short to mid term roadmap. We'll circle back to update with timeline once we've had a chance to prioritize the roadmap in a few weeks.

[Hardcorian]

Hello Max, thank you for the response. Please, no apologies, you do a great work for the community and give us a private ACME platform that works like a charm. If you need some guidances to install and configure the platform on CentOS 7 for users, ask me :)
Great news for a mid term, I will stay tuned to this possible feature.

[dopey]

Funny you should mention that. We definitely want to build rpms for centos7/8 along with the existing release packages. No one on the team uses centos so we just haven't gotten around to it. If you have any recommendations / examples that would definitely help a lot.

[Hardcorian]

Hello Max, the step-ca can be installed with the dpkg software installed in CentOS, and works fine. The step-cli, used to initialize the PKI, need to be downloaded as tar.gz and executed every time as a bash in the folder where is uncompressed. Once initialize, following your steps, I be able to change the self-signed certiticates by my RootCA cert and create a specific SubCA for this PKI.
As ACME client, I use certbot in Linux and win-acme in Windows, working fine in both cases. If I could provide you with more technical information, tell me.

[TheSecMaven]

I see this PR is closed, is this still expected to make it on the roadmap? Trying to find where I can follow this issue to see when it gets implemented, this would be a MUST have feature for enterprise adoption.

[mikemaxey]

@mkkeffeler - CRL & OCSB are still on the roadmap. It's helpful to understand the use case you are targeting as implementations can stray from standards. Can you (or anyone else reading this issue) share your target use case? Offline is fine as well, I'm at maxey@smallstep.com. thx

[mmalone]

At present I don't see another issue that more succinctly requests CRL. I'm gonna go ahead and reopen this for the time being so there's a public place for folks to express interest & give feedback.

@mkkeffeler, CRL and OCSP (CRL reporting, CRL management, CRL serving, OCSP reporting, OCSP responder, OCSP stapling) are all gonna happen eventually. That's all on our internal backlog. To reiterate what @mikemaxey said, specific use cases are helpful.

We're big fans of short-lived certificates and passive revocation (see https://smallstep.com/blog/passive-revocation/). We're more inclined towards improving support there versus adding CRL and OCSP. If there's a way we can make that pattern work for your use case, we'd love to hear about that.

But we recognize that, for a variety of reasons, CRL and OCSP are requirements for some folks. If that's the case for anyone reading this, a +1 helps us prioritize. A short comment (or email) explaining your use case is even better (and we understand that, for some orgs, the reason is that "because organization policy says so" or "because control X.Y of regulation Z says so").

Full disclosure: interest in this project is growing fast and we're spread pretty thin right now, so we're having to ruthlessly prioritize. I'm hesitant to mention this here, since it's sort of mixing religion with politics, but one thing that would accelerate this work is a customer who is actually demanding this feature. So far we've been able to talk customers out of this requirement when it's come up, so we haven't been "forced" to do it ;). That's not a hard requirement -- we do lots of stuff because it's the right thing to do -- but this particular feature is just slightly off of our utopian vision for the way we think PKI should work so it's a little harder to get excited about doing it without some encouragement. Again, not a requirement, but if anyone really needs this we're happy to discuss.

Aside from all that, there are some technical decisions to be made. One question I have is whether these features belong in step-ca core or if they're actually separate infrastructure that step-ca (and other CAs) can report to and that relying parties can utilize to determine revocation status. Any thoughts there are also welcome.

[TheSecMaven]

Our main use case is that we still work with lots of legacy clients and as such getting them to move to ACME is likely not a matter of prioritization but rather just not possible. Because of that we sign certificates for some clients for a longer term, such as 1 year or even 3 years in low risk cases. As such, the ability to passively revoke is irrelevant due to the length, so we need an active revocation strategy. I would also argue that for enterprise situations the ability to revoke all very large number of certificates and have that take effect immediately is a must have to properly secure the enterprise in a disaster event/security breach.

Would be happy to help drive this to completion in any way I can and coordinate/develop this.

[Hardcorian]

Hello, I am happy that the issue is reopen if it will help to accelerate the implantation of a scenario with CRL. I want to send a diagram of my environment to help to understand my need, but I have no way to send you right now.

We are interested in use a short-lived automated certificate, but with a CRL to the quickly revocation of the certificates. We use a unique Root CA for Windows PKI and Linux PKI/ACME server, and a issuing CA in each environment.
The important idea is that the certificates issued with ACME can have published the CRL, to allow the users and machines to know if the certificate is revoked. The revocation itself is relevant, but we can revoke the certificates by another ways, like openssl.

Hope that understand my explanation, I wil try to post later the complete diagram to help to understand better the case of use.

Thanks so much!

[mmalone]

@mkkeffeler that makes sense, with the caveat that ACME isn't your only option. I'm assuming that your legacy clients can't use any sort of automated certificate management, ACME or otherwise? If that's the case, yea, I get the need for CRL and/or OCSP.

@Hardcorian if your diagram is confidential feel free to email me. I'm mike at smallstep's domain.

[TheSecMaven]

that is correct @mmalone, we are having to accept the request via a ticketing system and manually sign it today. With this tool we could put ansible around it and automate the provisioning part, all that would be left is our manual review and then after approval the implementation could be automated, but to do that we would like to have a CRL.

How can I help get this implemented? is this a prioritization thing or is there work that I could do in my spare time on this?

[Hardcorian]

Hello,

I attached a little idea of our PKI with ACME v2 integrated, and two cases of use that requiring active revocation to work correctly.

As I said previously, the best option is to have a complete CRL (or OCSP) configuration in the PKI created by step, but a first good approach would be publish the CRL Distribution Point in the certificates with a flag like --crl http://cdp.corporation.es/example.crl when the certificate is created. In this way, if we need to revoke the certificate according to the cases of use, we are able to use openssl (for example) to revoke and add to this CRL.

Let me know if these cases of use are compatible with your roadmap, and if need further information.

Certificates revocation - Cases of use.pdf

[Hardcorian]

@mmalone @dopey Hello! Have you any update/planification about this issue? I need to know for a short-term, and assume the current scenario if we want to implement ACME if the planification is for long-term.
Thanks!

[dopey]

Hey, apologies for the delay. We're in the process of roadmapping as we speak. This project has gained some popularity recently. Enough so that deciding where best to allocate our limited time has become complicated (and contentious - we love to politely disagree with one another 🤪). It's a good problem.

As of right now, I can't give an accurate timeline for addressing this issue. Hopefully I'll have a more concrete update in a few weeks.

To give a bit of insight into our decision making process: we discussed both CRL and OCSP this morning. Basically, our opinion on both is ... nuanced. We believe that the right default for "most" use cases is passive revocation with short lifespan certs. Nevertheless, we understand that there are use cases where CRL and OCSP are must-haves. So we're left weighing the importance of those "non-default" use cases against other open issues that may have broader reach.

More input from the community (in the form of 👍 or comments on the issue) helps to make these decisions easier.

[Hardcorian]

Hello, yes, I know your general position regarding the active revocation, but in our current environment is useful to have the CRL implemented. For this reason, have a flag like --CRL is a simpler way to have the option to integrate inside the ACME server without a complete change of your position or code. But I understand the time is short for everybody, even the minimum change in a code requires effort.

Thanks for the feedback, I hope more people helps to take a final decision.

[mikehardenize]

We're also waiting for this support. We have an application which analyses the TLS configuration of our customers services, and we need to be able to generate certificates that contain CRL and OCSP URLs so that we can perform regression testing. We don't necessarily need the ability for step-ca to provide CRL or OCSP data, only the ability to add CRL and OCSP URLs to the certificates that it generates. Being able to set a default for ACME, but also arbitrary URLs when generating certificates via other means would be very useful to us.

[dopey]

Good to know.

@mikehardenize to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions.

If that's the case, then we are starting work on a project that should allow you do this (#300). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case.

[Hardcorian]

Hello, Also in our case, would be useful have a flags to add the rights extensions, like the CRL one. Thanks for the update! El jue., 25 jun. 2020 19:34, Max <notifications@github.com> escribió:

…

Good to know. @mikehardenize <https://github.com/mikehardenize> to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions. If that's the case, then we are starting work on a project that should allow you do this (#300 <#300>). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#206 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOTTBNRG6TL2ZEOWHD3XLX3RYODD3ANCNFSM4LFJK3TQ> .

[dopey]

Great point @Hardcorian. Our plan is to have the templates available on both sides (cli and step-ca). So when you're generating a cert via the command line you could add any extensions by specifying a template (complete with templatized variables).

We're wary of creating flags to add extensions because there are simply too many extensions / attributes in an x509 certificate and we don't want to muddle our commands by adding all those flags.

[mikehardenize]

@mikehardenize to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions.

Yes, that is the case. Ideally step-ca would serve up the CRL and OCSP responses, but I realise that's a bigger job and we have a workaround for that. Our main requirement is getting arbitrary CRL/OCSP URLs added to the certificates.

If that's the case, then we are starting work on a project that should allow you do this (#300). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case.

Yes, that would solve our use case, thanks. I'll keep an eye on that issue.

[TheSecMaven]

Is there any docs on generating a CRL on your own? or the equivalent OCSP? we are looking at hosting it somewhere else, and if we cant have this will use the cert templates as an alternative. this would be a huge feature, though as we are just building workarounds to having this.

[0xjac]

I would just like to share our use case as it might interest some people. We plan on using smallstep for certificates on both our servers and staff machines such that when a staff machine talks to an internal service, they can mutually authenticate each other.

Using passive revocation with short lived certificates is fine for our servers. However it is problematic for staff machines which are turned off every night, weekend, or even weeks for holidays. Thus we would like to have certificates lasting ~6 months for staff machines and generate a CRL file we can push (via devops) to all our services to check potentially revoked staff certificates (which can happen if their machine gets compromised or if they leave the company).

I would be happy to provide a simple PR which adds a command to locally generate a PEM CRL file on the CA, if you are interested? Hopefully you can then use it as a building block to develop CRL further (CA endpoint/ distribution info,...) for those who need it.

[mmalone]

@mkkeffeler unfortunately, I don't think we have any documentation on creating a CRL or setting up OCSP anywhere. Maybe someone else in the community can help. If you figure out a solution I'm sure others would appreciate hearing about it (I know I would).

@0xjac thank you for the feedback / use case. We are interested in adding active revocation functionality. At the moment we don't have a spec or architecture in mind. If you were to add a command to locally generate a CRL from the CA that'd be a decent start. I'm assuming you'd just pull the certificates that have been revoked (e.g., using step ca revoke) and add them to CRL? At the point you should be able to host the CRL on something like S3, and you should be able to use the upcoming certificate templates functionality to add the CRL distribution point to your certificates. I'm fine with you submitting a PR for this to unblock people who need this functionality. We may evolve the implementation and interface over time as we flesh out active revocation, but I'm sure lots of people would appreciate something like this added short-term.

@0xjac one other note regarding your use case... problems with cert renewal for "intermittently connected devices" (usually endpoints or IoT devices) come up pretty regularly. We're considering adding support for ACME-STAR renewal (or something ACME-STAR-like) [RFC8739] as an alternative renewal mechanism. The tldr is: instead of waiting for a client to request a certificate renewal, the CA would automatically renew any "active" certificates (i.e., certs that have not been revoked) and make them available at a well-known URL. That way fresh certificates are always available when a device comes back online, so long as devices retain their private key material between reboots. I still think we need active revocation, but would this functionality address your use case? Would you prefer it over longer-lived certificates?

[logopk]

@maraino @unreality I have written an exporter to openssl index.txt format to be served on a separate server, as base for the crl or in an OCSP responder.

In my case - as I do not have too much traffic on my CA - I have setup a filewatcher that monitors the badger db files, copies the db directory (as is) and then opens up the database in a separate process.

[ImNtReal]

@logopk would that be something you're willing to share?

[logopk]

Sure. I'm not sure how yet, but let me find a place to upload

[logopk]

So that's what I have hacked together (beware I'm new to go and there may be optimizations).

list.sh.txt
listcerts.go.txt

You can create the crl from index.txt or set an openssl ocsp process on it.

The next step would be the filewatcher that calls the writeIndex-function, when a new cert is added to the db and written to disk (if you want to use OCSP stapling the immediate update of index.txt is mandatory).

Let me know what you think...

[maraino]

Thank @logopk I've copied those to a gist

[DonOtuseGH]

how can i handle this? i'm not that familiar with badger and go and didn't find a way, how to work around this version issue...

# go run listcerts.go step/db
panic: manifest has unsupported version: 7 (we support 4).
Please see https://github.com/dgraph-io/badger/blob/master/README.md#i-see-manifest-has-unsupported-version-x-we-support-y-error on how to fix this.

goroutine 1 [running]:
main.main()
	/root/step-ca/listcerts.go:22 +0x225
exit status 2

[DonOtuseGH]

I would appreciate if there would be an option to generate CRL and/or OCSP information. For example, think of a web application that requires mTLS (client-side X.509 authentication) and clients/users that are not under your control or cannot be forced to use step/ACME client to authenticate with short-lived certificates.

[hslatman]

manifest has unsupported version

@DonOtuseGH: it seems there's a mismatch between the version of Badger you're trying to use and the version of Badger that wrote the database file. Version 7 corresponds to Badger v2, whereas version 4 is Badger v1. You can try updating your Badger version imported in listcerts.go by go get -u github.com/dgraph-io/badger/v3

CRL is currently WIP in #731.

[DonOtuseGH]

@hslatman thank you! but now it's complaining the other way round ;-)

# go run listcerts.go step/db
panic: manifest has unsupported version: 7 (we support 8).
Please see https://github.com/dgraph-io/badger/blob/master/README.md#i-see-manifest-has-unsupported-version-x-we-support-y-error on how to fix this.

goroutine 1 [running]:
main.main()
	/root/step-ca/listcerts.go:22 +0x1a8
exit status 2

I have solved it via the MySQL backend, which is more handy as there are no restrictions on the clients connected and no need to copy badger stuff out of the way.

[hslatman]

@DonOtuseGH: ah, sorry; I should've double checked and should've suggested go get -u github.com/dgraph-io/badger/v2 instead. Didn't realize the v3 was using another version of the storage format.

MySQL (or PostgreSQL) are indeed easier to work with than Badger if you want to work with the step-ca data.

[DonOtuseGH]

I definitely prefer using a SQL compliant RDBMS, but from what i've read so far PostgreSQL is still under development. I am definitely curious what information will be available via a postgres backend and how the new data model will look like. Hopefully, postgres will not be used as a k,v-store... 😁

[hslatman]

@DonOtuseGH: PostgreSQL support was added in the latest release of step-ca. The documentation at https://smallstep.com/docs/step-ca/configuration/#databases has not yet been updated, but the PR for it is done. Some example configurations can be found here: #854.

Unfortunately, the PostgreSQL support currently is also only a simple K/V store 😅

[charltonstanley]

Not sure if I should create a new issue for this or post it here instead, but here it goes.

https://smallstep.com/docs/step-ca/certificate-authority-server-production#enable-active-revocation-on-your-intermediate-ca

I'm trying to follow the steps at the link above to create a CRL signed by my root ca. How do i sign the CRL if my keys are in aws kms?

[hslatman]

Copying over (parts of) my answer on Discord for posterity:

I don't think we have something readily available for that at in our open source offering at the moment. We have support for automatic CRL generation in our product now, though.

It may still be possible to use other tools, like openssl, to sign the CRL with a key in AWS KMS. https://github.com/JackOfMostTrades/aws-kms-pkcs11 provides a way for OpenSSL to communicate with AWS KMS through PKCS11. From the looks of it you should be able to configure the ID of your private key and use that to perform signing operations.

[maraino]

@charltonstanley My objective at some point is to be able to use step to sign data using the KMSs that we support on step-ca, and we already support AWS KMS. So to do it programmatically using Go, you can use our awskms.CreateSigner as the signer in Go's x509.CreateRevocationList.

[charltonstanley]

@hslatman and @mmalone thank you! It would indeed be slick to at some point be able to use step to do this in the future :)

[logopk]

I don't think we have something readily available for that at in our open source offering at the moment. We have support for automatic CRL generation in our product now, though.

@hslatman That's good to know, however I don't see any documentation on that!?

Mind to share how to use it?

[Hardcorian]

I don't think we have something readily available for that at in our open source offering at the moment. We have support for automatic CRL generation in our product now, though.

@hslatman That's good to know, however I don't see any documentation on that!?

Mind to share how to use it?

Hello,

I do not know if there is documentation, but this is the related thread:

#731

As the creator of this issue, thanks to all the team.

[hslatman]

@logopk: regarding the functionality in the product: we're currently building the parts to make it self-serve. At this time it requires a manual setup through customer support.

Apart from that, there's indeed the work underway that @Hardcorian linked, which would allow users of step-ca to create their own CRL. Then there's also @charltonstanley's use case of being able to sign a CRL (and perhaps other data) created outside of of step using keys configured in step, which isn't currently supported, but may be in the future, as @maraino mentioned.

[tmartincpp]

@logopk @maraino : sorry to bother you.

Any chance to help me with this issue ?

$ go run listcerts.go db/ 2>&1 ; echo $?
# github.com/golang/glog/internal/logsink
/home/thomas/go/src/github.com/golang/glog/internal/logsink/logsink.go:123:41: undefined: any
/home/thomas/go/src/github.com/golang/glog/internal/logsink/logsink.go:172:67: undefined: any
/home/thomas/go/src/github.com/golang/glog/internal/logsink/logsink.go:305:45: undefined: any
/home/thomas/go/src/github.com/golang/glog/internal/logsink/logsink.go:385:75: undefined: any
# github.com/klauspost/compress/huff0
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:774:20: cannot convert out (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:775:20: cannot convert out[dstEvery:] (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:776:20: cannot convert out[dstEvery * 2:] (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:777:20: cannot convert out[dstEvery * 3:] (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:1013:20: cannot convert out (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:1014:20: cannot convert out[dstEvery:] (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:1015:20: cannot convert out[dstEvery * 2:] (type []byte) to type *[256]byte
/home/thomas/go/src/github.com/klauspost/compress/huff0/decompress.go:1016:20: cannot convert out[dstEvery * 3:] (type []byte) to type *[256]byte
# golang.org/x/sys/unix
/home/thomas/go/src/golang.org/x/sys/unix/syscall.go:83:16: undefined: unsafe.Slice
/home/thomas/go/src/golang.org/x/sys/unix/syscall_linux.go:1018:20: undefined: unsafe.Slice
/home/thomas/go/src/golang.org/x/sys/unix/syscall_linux.go:2289:9: undefined: unsafe.Slice
/home/thomas/go/src/golang.org/x/sys/unix/syscall_unix.go:118:7: undefined: unsafe.Slice
/home/thomas/go/src/golang.org/x/sys/unix/sysvshm_unix.go:33:7: undefined: unsafe.Slice
2

Before the go run I did : go get -v . without error.

My goal is to generate an index file to use with openssl ocsp.

Thanks!

[logopk]

@tmartincpp oh I'm not that familiar with go, but to me it does not seem to be caused by the source of listcerts.go (as it does not include any of the mentioned files).

To prevent any such interferences I build the program in a separate docker container (in golang:alpine image).

[tmartincpp]

Thanks @logopk , I might try it out.

edit: it worked!

Here is an example of a Dockerfile to use :

FROM golang:alpine
#
COPY files/listcerts.go /step/
#
RUN cd /step/ && \
	go mod init step && \
	go get github.com/dgraph-io/badger/v2

Then you can call the image with something like : docker run --rm --network none --read-only --security-opt no-new-privileges --tmpfs /tmp:exec -v ~/docker/step_db:/step/db -w /step/ step_listcerts go run listcerts.go db/.

[mrexodia]

In case someone is looking here because of Windows refusing certificates without CRL specified when using step-ca as your self-signed ACME server:

> curl https://cloud.my.lan
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

You can fix this by enabling CRL in ~/.step/config/ca.json (see here for the relevant code, otherwise undocumented):

        "commonName": "Whatever CA",
        "crl": {
                "enabled": true,
                "generateOnRevoke": true,
                "idpURL": "http://ca.my.lan:8000/crl"
        }

Additionally you need to set up a template (as mentioned in this thread). I had to do this for both my ACME and JWK provisioners:

                        {
                                "type": "ACME",
                                "name": "acme",
                                "claims": {
                                        "maxTLSCertDuration": "4320h0m0s",
                                        "defaultTLSCertDuration": "744h0m0s",
                                        "enableSSHCA": true,
                                        "disableRenewal": false,
                                        "allowRenewalAfterExpiry": false
                                },
                                "options": {
                                        "x509": {
                                                "templateFile": "templates/x509/leaf-crl.tpl"
                                        },
                                        "ssh": {}
                                }
                        },

The template is in ~/.step/templates/x509/leaf-crl.tpl:

{
        "subject": {{ toJson .Subject }},
        "sans": {{ toJson .SANs }},
{{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
        "keyUsage": ["keyEncipherment", "digitalSignature"],
{{- else }}
        "keyUsage": ["digitalSignature"],
{{- end }}
        "extKeyUsage": ["serverAuth", "clientAuth"],
        "crlDistributionPoints": ["http://ca.my.lan:8000/crl"]
}

The CRL will be available under https://ca.my.lan:4443/crl (the same HTTPS endpoint you use as the ACME server). Windows will no accept an HTTPS endpoint, so I did a quick Caddy reverse proxy to enable regular HTTP as well. This is my Caddyfile (I run step-ca on my router and port 80 was already taken, so I use 8000, but any port will work):

{
        http_port 8000
        auto_https off
}

:8000 {
        reverse_proxy https://ca.my.lan:4443 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
}

It's important to change both the crlDistributionPointers in leaf-crl.tpl and the idpURL in config.json to point to the HTTP endpoint http://ca.my.lan:8000/crl. If I figure out how to set up OCSP stapling (just a dummy that returns an acceptable response) I'll post a comment!

[hslatman]

@mrexodia that's a great example configuration, showing all the bits to getting it to work. Thank you! 😄

Yesterday we merged #1372, so that the CRL endpoint is now available on the HTTP server too. This should make life easier with Windows in the mix.

[mrexodia]

Thanks @hslatman I'll update when a new version is released! I didn't realize there was also an option to run an insecure server 😅

The updated guide would probably be to replace Caddy with the "insecureAddress": ":8000" setting.

Also wouldn't it be good to default to the insecure endpoint for the CRL's idpURL if it's enabled? Currently you have to manually set it to the HTTP one. Also it would be nice to set the crlDistributionPoints so a template isn't necessary, but I understand there might be some reservations for that...

[hslatman]

We don't advertise the insecure server more than is necessary. It was only used for the SCEP protocol before, because that's designed to run over HTTP. But it makes sense for CRLs too, so that's why I added those endpoints now too. You should indeed be able to run this without Caddy with "insecureAddress": ":8000".

Your suggestions absolutely make sense, but need a bit of thought. The CA can run with multiple DNS names and on multiple IP addresses, so we must be deterministic in which one is chosen (the first one makes sense, of course). It should still be possible to override it in that case. Automatically adding the crlDistributionPoints extension could also be based on that value. Support for CRL generation in open source was a community contribution, and building it out hasn't been a high priority for us so far, so that's why there are parts to it that can be improved.