1. 4

Presented at GopherCon 2017 as a Lightning Talk.

  1.  

  2. 3

    I don’t understand. You wrote a tiny webserver in Go so you could scan it with StartSSL and verify if your certificate chain was correct because the issuer has too many intermediates and bad documentation? Wouldn’t the “openssl verify” command be more than sufficient to see if your chain is valid? I feel like I’m missing something here, sorry.

    1. 1

      The actual dumb part of server configuration is

      This means you have to include the certificate chain in the correct order

      Why? Why can’t you just throw a bunch of certificates at a server and it will do the right thing?

      1. [Comment removed by author]

        1. 1

          Maybe I am misunderstanding this, but …

          This tool only works if you install your certs in it and then point your production server to this tool. Otherwise TLS domain name validation will fail.

          That doesn’t sound very practical. So if you are going to take your production site offline for this then you may as well just test the certificates live?

      2. 1

        Does this tool actually verify the certificate path?
        Does this tool do OCSP and CRL verification?
        Does this tool support the Brainpool, the FRP, and other elliptical curves (minus NIST P256)?
        Does this tool support verifying, and extending the verification of certificate extensions such as name constraints?

        This only seems like a wrapper over an already made implementation of TLS 1.2, I was looking forward for something new like 1.3 and RFC 5289, plus all of the mentioned above. Some of those are even lacking in openssl so…