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.

Subject of the issue

Hi, do you plan to support SCEP (https://tools.ietf.org/html/draft-nourse-scep-23) in your Client tool and server? I couldn't find it in your repository. It would be tremendously useful. If you support it in your client, it would help adoption and migration rate, i bet :)

Description

This pull adds a new API endpoint /crl that will return an on-demand generated PEM-encoded CRL. Fixes #206

The CRL is generated on-demand:

• if it is requested after the NextUpdate time specified in any previously generated CRL
• if a certificate has been revoked
• if no CRL has been generated previously

A new database table for storing the CRL named x509_crl is created when step-ca is launched.

A new interface CertificateAuthorityCRLGenerator is available for CAS object to implement. If they implement the interface, CRL lists will be created, otherwise a 'not implemented' error is raised when the request for CRL is made.

Subject of the issue

We are trying to implement step-ca as the certificate provider for client certifcates to Chromebook devices in our organization. Google Workspace uses SCEP protocol to request certificates. Here is some of Google's documentation on this, they mostly refer to Windows ADCS as SCEP service: https://support.google.com/chrome/a/answer/11053129?hl=en&ref_topic=6330253 https://support.google.com/chrome/a/answer/11338941?hl=en

But there is no technical limitation from Google's side on which CA service to use. I have built a test enviroment that can issue SCEP certficates and testing the basic issuing using the application "sscep".

These parts are all working using the sscep client software, however when we test with a Chromebook we get the error: scep post request failed: pkcs7: Message digest mismatch

Your environment

• OS - Windows Server 2016
• Version - step-ca 0.18.2

Steps to reproduce

I've attached a Powershell script that i use to build the entire CA (and optionally install as a service using "shawl"). I've also attached a zip containing the exact executables i use for reference. TestEXE.zip WindowsCA.ps1.txt

But specifically these are used in addtion to step 0.18.2: Shawl - https://github.com/mtkennerly/shawl - Pre-compiled version 1.1.0 ( not needed if not installing as a service) SSCEP - https://github.com/certnanny/sscep - Self-compiled binary for Windows based on v0.10.0 OpenSSL - https://slproweb.com/products/Win32OpenSSL.html - using win64 v3.0.2

For testing with Google Workspace and Chromebook, we have set up a SCEP profile with these settings (omitted setting are blank/default):

• Profile Name: SCEPTest
• Subject name format:
  • Common name: ${DEVICE_SERIAL_NUMBER}
• SAN: None
• SCEP Server URL: <hostname:port>/scep/scepca
• Challenge type: Static
  • <challenge password>
• Certificate Authority: <Intermediate CA certificate>
• Device plattforms: Chromebook

Obviously you need a Google Workspace and Chromebook to set this up. The Google Certificate Connection got installed using a local user on the server (because the installer required it), and then the service was changed to use "LocalService" through Windows Services.

Expected behaviour

Expected that the Chromebook would complete the certificate request. Request is passed to step-ca with Google Certificate Connector as a proxy relay (certificate request flow is decribed in Google's documentation "Configure SCEP with ADCS for Chromebooks" as Appendix A). But short version is that Chromebook sends request to Google Workspace, then the Certificate Connector polls Workspace for any pending request. If request are pending they get pulled by the connector for signing and are pushed back to Workspace after signing is complete, afterwards Workspace push the certficate to the Chromebook.

Actual behaviour

Certificate request goes through, but final signing from step-ca seems to fail with error scep post request failed: pkcs7: Message digest mismatch.

Additional context

We managed to extract one of the failed requests. Since the request itelf only contains test-data there is no issue with sharing it here:

-----BEGIN CERTIFICATE REQUEST-----
MIICxTCCAa0CAQAwITEfMB0GA1UEAwwWTlhHTThFRDAwMTcxMzFGM0FCNzYwMDCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJkC7drW2oguTG0p4Ap2IltR
xyuaN/q1FhCaacfVFSpnFh6rNG9TQL0ZWQohN1EVRc6GoRYxVmaBBNAblf8D7sLV
ukjOQVFoXMvN9PGP0l58PDlGhWjAHGl6qW6dWqmvDjNE1L8CjTs65kN3TZqiWuIt
xqu4PmPd+DbuxmNDYdmiwZMK2edxiEV3Kbh+A+Q5QL3rgsXa2M5n5FO7s1X22sEp
BZSA6ZFkRMXEHcMutM1nIVAbqBEsYP1UbE/z43dKFPXr6jIxM3vloLRFyN5mBMFt
IvnrY6fAqR6m63c+axVqIrIoDu4ZTE5fd1knIuMvy8FHI+yPU+oObLcESTU03TUC
AwEAAaBfMBkGCSqGSIb3DQEJBzEMEwpzZWNyZXQxMjM0MCAGCSqGSIb3DQEJDjET
MBEwDwYJKwYBBAGCNxQCBAIMADAgBgoqhkiG9w0BCRkDMRIEEL11G+P9INKWkI8/
cAPTg+UwDQYJKoZIhvcNAQELBQADggEBAFwRRGxiq+3BphGyiJ+xF4aX+aRdAwjf
9ouNcVR34eRB60EZssHmT1UDm22W/4MXXN0AtuO47MF1p5vP7f75DTkXQ/whqKI1
CrGhnCzw1w2oMXdBXfUFem+svCHdxjvPMjA97km464kh0L6AeHt26oMDBHVvhaz/
rbMSQejHN6tNDHpG8kaaXS20SfaETpJYvDRx6IwzryJibOUPAz2V3ODEeFbQyXD3
DIHKV6NsZoP34JqZlYyPpOTTKcgUT7FZ1QjomD4mNU7YV9hwbrixAmuUuc64g1QX
wR5/t0Or/OXDXGHi/04X/86KLXoLPgRiTYkjdkAkrf8PNh0klaczcXY=
-----END CERTIFICATE REQUEST-----

Of note a difference with the test performed via OpenSSL made request and the request from the Chromebook is this (after decoding the request via OpenSSL):

        Attributes:
            challengePassword        :secret1234
            1.2.840.113549.1.9.25.3  :unable to print attribute
            Requested Extensions:
                1.3.6.1.4.1.311.20.2:
                    ..

Subject of the issue

I got this bug while trying out step-ca on WSL: https://github.com/dgraph-io/badger/issues/722

Error opening database of Type badger with source /tmp/step/db: error opening Badger database: Unable to mmap RDWR log file: exec format error

According to the comment at the end, it was fixed when upgrading to badger 2. step-ca still currently uses 1.5.3.

Your environment

• OS - Windows 10 with Ubuntu WSL

Steps to reproduce

Use Windows 10 WSL version 1909 OS build 18363.535, get ubuntu wsl. Get step-ca. And try running it after step ca init --ssh.

Subject of the issue

The step-ca container health state is shown as Up (health: starting), later it will turn to Up (unhealthy). But the service runs fine and it also logs that it is listening now, so apparently the health check always fails.

Your environment

• OS: WSL 2
• Version: 2 (Windows 10 x64)

Steps to reproduce

docker-compose.yml:

version: '3.7'

services:

  # Smallstep Step CA
  step-ca:
    image: smallstep/step-ca:0.15.6
    restart: always

> docker-compose up -d
> docker-compose ps
Up (health: starting)
# after some time (about one minute)
> docker-compose ps
Up (unhealthy)

Expected behaviour

As the CA service runs correctly, the health check should pass and the container state should become Up (healthy) or similar, but not Up (unhealthy). Also the health check needs too long ((health: starting)) for one minute.

Actual behaviour

Health check needs too long (Up (health: starting)) and then fails after about a minute (Up (unhealthy)).

What would you like to be added

There is a extension to ACME to allow it to verify ip addresses.

The extension is: https://tools.ietf.org/html/rfc8738

Why this is needed

This isn't something that Let's Encrypt will ever do but for locally hosted ACME provisioners it would be useful to get rid of certificate errors for sites when accessed via their local ip address. In our organization, we have very little standardization of hostnames (mostly due to acquisitions of other companies and systems) so often we just remember the IPs.

It's currently possible to use templates to force an ACME provisioner to sign any IP address that is passed to it but it will not perform any challenge. This defeats the security of ACME.

What would you like to be added

Hi, We would like to leverage smallstep certificates as issuing CA (3rd in the hierarchy) but we have problem on how to setup CA to serve the chain correctly (I think it's not possible at all?).

Why this is needed

As an organization, we are using 3 tier hierarchy where Root and Intermedate CAs are not under our control and we do not have access to a corresponding private keys.

Hierarchy should look like:

Root CA (HSM protected) -> Intermediate CA (HSM protected) -> Smallstep CA (issuer, software only, serving the whole chain to the ACME clients)

I tried to modify config file to serve our need, but I can't make it work with this kind of chain. There is #87 but I can't decide if it's duplicate or other use case as I don't want to manage CAs in hierarchy with smallstep certificates at all.

Thank you for making great software, Peter Gasper

Currently when we step ssh login identity via OAuth provisioner, only the email and its derivatives are retrieved. It would be great if we can add to these primarily so we can add:

• .Token.preferred_username: reason is self-explenatory
• .Token.groups: useful if we add something like "admins": ["/admins"], where the argument is a group.

So similar to the "SSH Group Accounts" available in the documentation, but at the login stage.

Subject of the issue

I use step-ca as an ACME directory for other services, Caddy being the biggest consumer. I've noticed that often renewal transactions are not completing. They work just fine for a while, both issuing and renewals, but then they stop renewing.

Your environment

• OS - CentOS 8.1.1911
• Version - 0.14.4
• Podman - 1.9.1

Steps to reproduce

I just followed your blog post on how to set up the ACME server, then configured Caddy to use the url.

Expected behaviour

Certificates needs to be renewed.

Actual behaviour

Certificates are not renewed, with the following log entry:

time="2020-05-29T11:07:02+02:00" level=error duration=38.041128ms duration-ns=38041128 error="error creating order: error storing order IDs for account xxxx: failed to commit badger transaction: Transaction Conflict. Please retry" fields.time="2020-05-29T11:07:02+02:00" method=POST name=ca nonce=xxxx path=/acme/acme/new-order protocol=HTTP/1.1 referer= remote-address=x.x.x.x request-id=xxxx size=228 status=500 user-agent="CertMagic Caddy/2.0.0 xenolf-acme/3.6.0 (release; linux; amd64)" user-id=

Subject of the issue

certificates 0.14.4 issues certificate with invalid extended usages

Your environment

• OS - step-certificates via helm chart on k3s on ubuntu
• Version - 0.14.4

Steps to reproduce

Given this certificate request, I'm getting back a cert with a bad EKU

-----BEGIN CERTIFICATE REQUEST-----
MIICkjCCAXoCAQAwADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJZ
gT0nkioqdRbBOffTRY3zE0k3u8D5sGQJ4CrhwrL1K3i5VsxsbIGcy6pY3jltzMyf
qh7F3KeKE+DHL9rpkJ8V2nl29aobs9iu9N4R520b1TZYmcFiwsvM19NGIIQLLmMl
Z43yEUuYPq1Ot0jIe+EexdFbhct0ZD6IlQH8RGs8Djpl8qRjEKvbpoC038TQyH5s
GfYLmEFfIAGzPYxPqrYI1IPOjdVbYb7EHuc/SoSfqn0+5/qPTL1HG6IdUPQ0rY/e
yKiJVoQcWIfdrX0pT6KM/2ytSBqllqIDsAgskjKdEm3bS93EZGMWIkzPy943x+0H
2CNpYtkhBTFHgsXVJ2kCAwEAAaBNMEsGCSqGSIb3DQEJDjE+MDwwIgYDVR0RBBsw
GYIXdGhlbG91bmdlLnN2Yy5kaW5oZS5uZXQwCwYDVR0PBAQDAgWgMAkGA1UdJQQC
MAAwDQYJKoZIhvcNAQELBQADggEBAEYVlFQWlEt4AIgXIjeK91rcPj3TsFp0wxso
rUNmhC+5F0GlyYvlQKXhMAgZvV3TEVu6pFfXV6Cfgz4VHycV1EYWBK4ZNNEI8MVM
OgfzfwgCFyrLlPE1dz62gh+wez2HcTQ5PRHKXOcwx2kfDXZzXYoQspXKtijr7GLO
/wfRjPFhD7ARXYEYCcR09JiJSt8vCWZIY89tjkrZzfWt8pbcRTLaqx75bHC9iqvR
UxPXGQvgHjtgYj/OB6rTtV+zhaPLa0L9Is5HrBPrR15H97b6UsH/DxtZ9iBLOTEz
EhL9/KVilNc3tjhL8ITtRNtypJdZWirXWao6hZDDMr56n1eO56o=
-----END CERTIFICATE REQUEST-----

            X509v3 Extended Key Usage: 
                0.

With 0.14.4:

-----BEGIN CERTIFICATE-----
MIIClDCCAjugAwIBAgIRAIO95tukZmrpI0yx9Ghz3scwCgYIKoZIzj0EAwIwLDEq
MCgGA1UEAxMhU3RlcCBDZXJ0aWZpY2F0ZXMgSW50ZXJtZWRpYXRlIENBMB4XDTIw
MDkwNzAyNDYwNVoXDTIwMDkwODAyNDcwNVowADCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAOJZgT0nkioqdRbBOffTRY3zE0k3u8D5sGQJ4CrhwrL1K3i5
VsxsbIGcy6pY3jltzMyfqh7F3KeKE+DHL9rpkJ8V2nl29aobs9iu9N4R520b1TZY
mcFiwsvM19NGIIQLLmMlZ43yEUuYPq1Ot0jIe+EexdFbhct0ZD6IlQH8RGs8Djpl
8qRjEKvbpoC038TQyH5sGfYLmEFfIAGzPYxPqrYI1IPOjdVbYb7EHuc/SoSfqn0+
5/qPTL1HG6IdUPQ0rY/eyKiJVoQcWIfdrX0pT6KM/2ytSBqllqIDsAgskjKdEm3b
S93EZGMWIkzPy943x+0H2CNpYtkhBTFHgsXVJ2kCAwEAAaOBnjCBmzAdBgNVHQ4E
FgQUbZfhBTtYHTGQ8/D+dG32tIr2bIwwHwYDVR0jBBgwFoAUypa8cecPKOHjicLq
z8C5I+nBrX8wIgYDVR0RBBswGYIXdGhlbG91bmdlLnN2Yy5kaW5oZS5uZXQwCwYD
VR0PBAQDAgWgMAkGA1UdJQQCMAAwHQYMKwYBBAGCpGTGKEABBA0wCwIBBgQEYWNt
ZQQAMAoGCCqGSM49BAMCA0cAMEQCIHUDmscr0t4wOyLW5rmCFpwQ+8qg4hyHyamJ
0Z86dVtKAiAtYSyOoOipes8rOqaiz4gU+rF9hkfYbsUmp6m+xvUJIw==
-----END CERTIFICATE-----

            X509v3 Extended Key Usage: 
                0.

With 0.14.3:

-----BEGIN CERTIFICATE-----
MIICrzCCAlWgAwIBAgIRAPwUGst/8XQoXt+Xbk7Txu8wCgYIKoZIzj0EAwIwLDEq
MCgGA1UEAxMhU3RlcCBDZXJ0aWZpY2F0ZXMgSW50ZXJtZWRpYXRlIENBMB4XDTIw
MDkwNzAyNTE0MloXDTIwMDkwODAyNTI0MlowADCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAOJZgT0nkioqdRbBOffTRY3zE0k3u8D5sGQJ4CrhwrL1K3i5
VsxsbIGcy6pY3jltzMyfqh7F3KeKE+DHL9rpkJ8V2nl29aobs9iu9N4R520b1TZY
mcFiwsvM19NGIIQLLmMlZ43yEUuYPq1Ot0jIe+EexdFbhct0ZD6IlQH8RGs8Djpl
8qRjEKvbpoC038TQyH5sGfYLmEFfIAGzPYxPqrYI1IPOjdVbYb7EHuc/SoSfqn0+
5/qPTL1HG6IdUPQ0rY/eyKiJVoQcWIfdrX0pT6KM/2ytSBqllqIDsAgskjKdEm3b
S93EZGMWIkzPy943x+0H2CNpYtkhBTFHgsXVJ2kCAwEAAaOBuDCBtTAOBgNVHQ8B
Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQW
BBRtl+EFO1gdMZDz8P50bfa0ivZsjDAfBgNVHSMEGDAWgBTKlrxx5w8o4eOJwurP
wLkj6cGtfzAlBgNVHREBAf8EGzAZghd0aGVsb3VuZ2Uuc3ZjLmRpbmhlLm5ldDAd
BgwrBgEEAYKkZMYoQAEEDTALAgEGBARhY21lBAAwCgYIKoZIzj0EAwIDSAAwRQIh
AP4CKHPOT8pd+JJ8Xf2fbf384sJgmzcOTdBDyYJ5hVnAAiAvzMzPrwinPVjDSfwH
t434ZiYmJtZzzgiAgrqDHMhbEQ==
-----END CERTIFICATE-----

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication

Expected behaviour

Either warn that a cert is being generated with a bad EKU, or apply defaults as 0.14.3 did.

Actual behaviour

A useless cert is generated

Additional context

This cert request is generated by cert-manager 1.0.1, so there may be other components at play in this.

Steps to Reproduce

1. Install step-ca as a POD in k8s with Deployment of 1 ReplicaSet accessible via Service
2. Install cert-manager (1.8.0 in my case)
3. Create at least one [Clluster]Issuer (apiVersion: cert-manager.io/v1)
4. Create one Certificate in some namespace (apiVersion: cert-manager.io/v1) It should work well. ...
5. Delete the certificate you have created and the TLS secret corresponding to that certificate
6. Restart the step-ca POD (e.g. delete the POD)
7. Recreate the cert, by appliying the same manifest... Results/Messages:

• cert-manager Order: Failed to create Order: 400 urn:ietf:params:acme:error:malformed: The request message was malformed
• cert-manager CerificateRequest: order is in "errored" state: Failed to create Order: 400 urn:ietf:params:acme:error:malformed: -step-ca: kid does not have required prefix; expected https://<STEP_CA_SVC_NAME>.<STEP_CA_NS>/acme/acme/account/, but got "

Your Environment

• step-ca v0.15.14
• cert-manager, helm chart v1.8.0
• k8s/GKE

Expected Behavior

Working in k8s environment should not implies on the behaviour of the step-ca and cert-manager.

Actual Behavior

Iimagine what happens with all cert-manager issuers when step-ca pod is being restarted (due to standard autoscalling jobs, or other thing)? Every client (issuer in cert-manager terminology) must be restarted (in my case removed and being recreated)?

Additional Context

I do not know what is the place of origin of the problem: either step-ca or cert-manager so, I'm preparing two issues (one here and the other one in cert-manager project): cert-manager/cert-manager#5666

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Description

This PR will ignore principals validation when an OIDC provisioner is used. When the principals in the server do not match the principals given, the validation was failing, even if templates or webhooks set the proper principals. With this change, OIDC will not validate the principals and will just set the default ones (name, [email protected]) plus the ones in the templates.

This PR also includes a change in the templates to allow setting the provisioner to the $(step path)/ssh/config template

Related to smallstep/cli#807, #900 cc @Janhouse

A problem could occur in which the SCEP challenge password would not be set to the proper value when provided through the CLI because of how provisioners were or were not initialized. Redaction of the challenge secret has been moved to the MarshalJSON function of the ProvisionersResponse in the api package.

Steps to Reproduce

1. Do the ssh host attempt using OIDC SSO without doing step ssh login and without doing ssh host attempt beforehand.

• Every time before running ssh host run step ssh logout to trigger login mechanism

Your Environment

• OS - Archlinux
• step-ca Version - 0.23.0

Expected Behavior

It should create the certificate, add to the agent and log you in the server by starting ssh handshake.

Actual Behavior

Certificate it created, added to agent but login fails with Bad packet length on client side and Bad protocol version identification '' from sshd side. Client starts the handshake by sending the cypher list, skipping the first step.

Additional Context

The ssh host command and proxycommand works correctly if the certificate is already made and added to agent. If it has to be made and added to agent in one try, it fails because SSH handshake fails.

proxycommand for some reason step cuts the initial handshake message containing SSH protocol version. From wireshark it looks like this:

Meanwhile, on subsequent tries and when certificate has been added in any other way, the handshake part looks like this:

This issue has been previously mentioned in https://github.com/smallstep/certificates/pull/561#issuecomment-828989785 but it was not addressed and no bug report was made.

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Steps to Reproduce

Out current setup:

1. We have three step-ca servers running off the same mysql backend.
2. The CA servers are configured to use keycloak as an OIDC provisioner.

Steps to reproduce:

1. step ssh login <keycloak-user-email-id>
2. Login into keycloak via the web interface the step client opens.
3. After logging in, the webpage says token can be found in the command line but the terminal says The certificate authority encountered an Internal Server Error. Please see the certificate authority logs for more info. Re-run with STEPDEBUG=1 for more info.
4. Logs from the CA server say

time="2022-11-21T05:41:36Z" level=error duration=2.102361ms duration-ns=2102361 error="authority.Authorize: authority.authorizeSSHSign: failed when attempting to store token: error storing used token used_ott/: commands out of sync. You can't run this command now" fields.time="2022-11-21T05:41:36Z" method=POST name=ca ott= path=/ssh/sign protocol=HTTP/2.0 referer= remote-address= request-id=cdtgv43l6md73t0rqkhg size=148 status=500 user-agent="Smallstep CLI/0.22.0 (darwin/amd64)" user-id=

MYSQL documentation says the error commands out of sync. You can't run this command now occurs when in the client code, you are calling client functions in the wrong order - reference

Your Environment

• OS - Alpine Linus 3.16 via step-ca's docker image
• step-ca Version - smallstep/step-ca:0.23.0 Docker image
• MySQL version - 8.0.30

Expected Behavior

That the CA server signs the users key without any error.

Actual Behavior

After the OIDC provisioner authentication step is done, the CA is erroring out when it's trying to communicate with it's mysql backend in the process of signing the authenticated user's public key.

Additional Context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).