Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    I don't think is going to be super hard,
    we will implemented at some point, but I can't tell you when
    what you should do is to create an issue https://github.com/smallstep/certificates/issues/new/choose
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Will do.
    Mariano Cano
    @maraino
    We have an internal discussion an prioritization of those issues every Tuesday. You just missed it, but I can talk it about internally before that. Just add the issue
    If you have a special use case for using IPs instead of DNS, make sure to add that to the issue, it might help with prioritization
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    Mostly our DNS is a mess since the different hostnames were setup by different people over many years and we've acquired so many smaller companies which each had their own systems. As a result we do a lot through ip address.
    I'm sure we're not the only organization that has problems like that.
    Issue submitted. Thank you very much.
    Mariano Cano
    @maraino
    Not the better solution, but something that can help is also to have a centralized server doing some kind of custom validation and providing a Token for use with JWK provisioners
    thanks
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    I'll look into that. Thank you.
    Mariano Cano
    @maraino
    @mquinnatlasroofingcom : by the way do you know if the client that you're using support the IP validation? Which one are you using?
    the acme client
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    It's POSH-ACME. As far as I can see it doesn't really support IP addresses as such it treats them as DNS names and passes them over as a string.
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    In playing around with the code yesterday I found that I could change order.go at line 386 from "Type: x509util.DNSType" to "Type: x509Util.IPType" and it would send back a signed signature with the correct san type. This was simply a proof of concept since it now doesn't work for DNS names at all. I'm thinking of adding a pattern match so if the name looks like an IP it's signed as an IP and if it doesn't then it's signed as DNS. I'm pretty sure that will work but I'm a little concerned that it will break something else or render something insecure. What do you think?
    Mariano Cano
    @maraino

    @mquinnatlasroofingcom that will only work if the CSR is "malformed" and has the IPs marked as domain names. I don't think we will accept that change at the moment, but when we add support to IP Validation in ACME is something that we might add if this is what the clients does.
    Right now I guess you can build your own step-ca with a change there and try.

    I'm not sure if it will work, but it can be something like:

    typ := x509util.DNSType
    if net.ParseIP(csr.DNSNames[i]) != nil {
       typ = x509util.IPType
    }
    ...
    mquinnatlasroofingcom
    @mquinnatlasroofingcom
    What I'm talking about here is a dirty hack and definitely not the way you'd want to do it in a released product. But as a purely internal solution I'm thinking it will probably work. Unless you can think of a security flaw in what I'm proposing.
    Mariano Cano
    @maraino
    not at the moment, as long as the challenge also works