Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Max
    @dopey
    No bad questions @do_avian_twitter , although I’m not exactly sure what you’re asking. step-ca can sign certificates in return for OIDC tokens. So you can use your Gsuite, Okta, etc. as authentication to get X.509 or SSH certificates.
    Avian Do
    @do_avian_twitter
    yes, i got it by that way
    and from this video as well:
    https://www.youtube.com/watch?v=ZhxLRlcNUM4
    westwin
    @westwin
    Hi, I'm wondering how to do the authorization with smallstep ssh login. I mean user1 is granted the perm to login host1, but can not login host2
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    I'm trying to use a self hosted step-ca acme server to provide certificates to a windows based client that will be installed in iis (among other things) in our organization we often visit sites via their internal ip addresses. I've had no problem using stepca to provide certs that work for internal domains but the ip's are problematic. I know you can't use le to provide certs for ips but can a self hosted acme server do it?
    Max
    @dopey
    Hey, @mquinnatlasroofingcom, great question! step-ca adheres very closely to the original ACME spec, which did not support IPs. There is however a draft ACME spec for supporting IP addresses, but not supported by step-ca as of yet.
    You should definitely open an issue to track it, if it’s something you’d like to see added. In the mean time you’d have to use one of the other provisioners.
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    I've managed to get my acme clients (both acme.sh and posh-acme) to produce a certificate that has sans for dns:domain.example.com and dns:192.168.15.132.
    The problem is that 192.168.15.132 isn't a dns name so it throws a certificate error.
    If I sign the certificate with the default step ca certificate create <...> --san=192.168.15.132 it automatically detects that it should change the type of that san.
    Is there some way to do something similar with a template for the ACME provisioner. Automatically recognize when an IP has been passed in and change the type?
    Max
    @dopey
    @maraino do you know if this is possible? even if the ACME provisioner did assume that the additional SANs were IP addresses (rather than DNS names), our logic on the backend would still fail because we can’t validate IP addresses (I believe).
    The only thing I can think of would be using a bespoke template on each client host that added a hardcoded IP address SAN.
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    It is validating ip addresses. I'm doing http01 challenges. I assume that it's just as happy to check http://(ip address):80 <...> as it is to check http://(domain name):80<...> . Is there no way in the template to parse a string. Forgive me if that's a dumb question I'm just getting into how templates work.
    Perhaps automatically change the third san to type IP?
    Max
    @dopey
    no, honestly it’s a good question. I’m just not all that familiar with the inner workings of templates either. Mariano is the expert. He should be by in a a few.
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Thanks.
    Max
    @dopey
    Just so I understand correctly, basically, you’re able to get the certificate with a ip address in the SANs (we’re able to validate it etc.), but unfortunately it’s a DNS name SAN, not an IP name SAN.
    That’s definitely baked into the code. And for good reason, since the ACME did not originally allow for IPs. Not sure if that’s something templates can help with though. We’ll see.
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    That's correct. It returns a signed certificate (from multiple clients so it's not funny business in the client side). The certificates lists two sans both of type dns one a domain name and the other an ipaddress
    Max
    @dopey
    Got it.
    Mariano Cano
    @maraino
    @mquinnatlasroofingcom @dopey the current implementation of acme does not support IPs, but there's a trick that you can use on templates to allow this. If the CSR has ip addresses in it, they can be accepted if we add a template like this
    {
        "subject": {"commonName":"{{ .Insecure.CR.Subject.CommonName }}"},
        "sans": {{ toJson .SANs }},
        "ipAddresses": {{ toJson .Insecure.CR.IPAddresses }},
    {{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
        "keyUsage": ["keyEncipherment", "digitalSignature"],
    {{- else }}
        "keyUsage": ["digitalSignature"],
    {{- end }}
        "extKeyUsage": ["serverAuth", "clientAuth"]
    }
    BUT THEY ARE NOT BEING VALIDATED
    At some point we should support the acme extension to support IPs https://tools.ietf.org/html/rfc8738
    The same trick can be used to accept email addresses or uris
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    I'm kind of winging it here so forgive the basic question, but I put that text in a file acme.tpl in the step-ca/templates directory and set the templatefile attribute to templates/acme.tpl and it should work?
    Mariano Cano
    @maraino
    you can configure a provisioner like this
    {
                    "type": "ACME",
                    "name": "acme",
                    "options": {
                        "x509": {
                            "templateFile": "templates/certs/x509/leaf.tpl"
                        }
                    }
                }
    for templates that path is relative to the step path
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Perfect. I understand more than I thought I did.
    Mariano Cano
    @maraino
    but it can be a full path if that does not work
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    The HTTP01 challenge will still happen on both the ip and dns correct?
    Mariano Cano
    @maraino
    so in my environment that is ~/.step/templates....
    no
    only on the DNS
    We don't support yet rfc8738 that would do the validation on IP addresses
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    So then the provisioner would sign a certificate for any ip address that someone feeds it even if it's not actually associated with the dns name that it verifies?
    Mariano Cano
    @maraino
    yes
    but only if you add that custom template
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Rats. That kind of defeats the whole point of the acme verifications then.
    Mariano Cano
    @maraino
    the only solution for acme, is to add to support to the IP validation extension
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Better idea. Is there a way to set up a template and then automatically insert the result of a nslookup as an extra san?
    Mariano Cano
    @maraino
    no, a template cannot execute programs
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    and it can't do a program could it call a go function that does the same thing?
    Mariano Cano
    @maraino
    with a custom build you can add a function that does that
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    I think I know what I'm doing with the rest of my week.
    Thank you very much. You've been most helpful.
    Mariano Cano
    @maraino
    I would rather implement the IP extension instead of adding that function :)
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    You mean you don't want to drop everything to implement something weird for just one person? Can't imagine why.
    Really, thank you so much. Now I know exactly were on the brick wall I should be beating my head.
    Mariano Cano
    @maraino
    I don't think we are going to accept the PR with that function
    but we will accept a PR with the IP extension implemented