<p>I try to verify if a provided certificate chain is sufficient for a service.</p>
<p>Could be easy with <a href="https://golang.org/pkg/crypto/x509/#Certificate.Verify" rel="nofollow">Certificate.Verify</a> by adding the provided certificate chain into <a href="https://golang.org/pkg/crypto/x509/#VerifyOptions" rel="nofollow">VerifyOptions.Intermediates</a> and compare the result.</p>
<p>But it starts to become tricky, if the server certificate is located in /etc/ssl/certs/. Now this server certificate is treated as a root certificate and the Verify function only returns this certificate without the chain.</p>
<p>Well, this behavior is fine for the verification part, because the certificate is obviously trusted, so no need to track it down to the root certificate.</p>
<p>But it's bad for my use case, because I want to check if it's also ok for other clients who needs to verify the certificate down to the root cert.</p>
<p>And now the <a href="https://golang.org/pkg/crypto/x509/#CertPool" rel="nofollow">CertPool</a> turns out to be useless. I can fill it with the system known certificates (<a href="https://golang.org/pkg/crypto/x509/#SystemCertPool" rel="nofollow">SystemCertPool()</a>) and also add new certificates, but I can't get certificates out of the pool. Why? I can get the [raw] Subjects, but this won't help to verify anything. What is Subjects() used for at all?</p>
<p>Is it a bug or a feature, that a host certificate is treated as a root certificate?</p>
<p>A CertPool.DelCert function would do the trick. Or at least a CertPool.Certificates function. Any chance for a feature request?</p>
<hr/>**评论：**<br/><br/>0fbe: <pre><p>Why would you put the server-certificate in /etc/ssl/certs/? </p></pre>Chohmoh: <pre><p>You find certs/ and private/ below /etc/ssl/. If the host key is stored in private/ the certificate comes to certs/.</p>
<p>And the whole point of the check is to help other admins to setup the service. It's not my server the service is running on, so I can't control how others setup their systems.</p></pre>epiris: <pre><p>There is a lot of noise here, but you never specify your actual problem. What is a "users certificate chain", what qualifies sufficient and what is the transport. It sounds like you are simply trying to perform client certificate validation over TLS- and over complicating the process.</p>
<p>Do you maintain your own CA? If yes then you will need to clarify what your doing here because it sounds like clients are sending you intermediate certificates, which you state you want to add to certpools .. which could be a major security issue, as a client could send its own self signed root and be trusted by your entire system.</p>
<p>Clients typically have only the roots installed, the ServerHello in tls negotiation will send the intermediates it trusts when requesting client cert authentication and optionally the root cert. The cert sent by client should be signed by the tail of the chain sent by the server, and the head of the chain sent by the server should be validated by the client to be signed by or in it's own trusted roots.</p>
<p>So, knowing this we can add a certificate chain to a separate certpool (see my post history about this) and use it for our tls config, client certificates will be built during negotion for you. This means we have our chain from head covered by the server, and only need to validate the tail sent by client. No modification of our certificate store required, just set RequireAndVerify (check full name/google) in tls config to require client cert auth and let Go do the rest for you.</p></pre>Chohmoh: <pre><blockquote>
<p>you never specify your actual problem.</p>
</blockquote>
<ul>
<li>I'm writing a program which offers a service over TLS.</li>
<li>Other people will setup this program on server I never saw.</li>
<li>I want to make the use of this program as easy as possible.</li>
<li>A lot of people don't know much about TLS. So you'll find a lot of badly configured services.</li>
<li>I do automatic checks to prevent misconfigurations.</li>
<li>I can't check the certificate chain which guys (I don't even know) provide on hardware I never saw.</li>
</ul>
<blockquote>
<p>What is a "users certificate chain"</p>
</blockquote>
<p>I never said anything about that. And obviously I wasn't able to explain the problem without causing misunderstandings, sorry about that.</p>
<p>It's all about helping strangers who happens to use my program setting up the TLS stuff in the correct way.</p></pre>epiris: <pre><p>While your intent is good- don't. Lots of people have already documented how to setup TLS, manage a CA, etc. Adding more moving parts around cryptography primitives is ways for subtle mistakes to happen. Not to mention the additional checks you will create will fail on windows cert stores which operate completely differently and you would need to import unsafe to make calls to it. </p>
<p>The best thing you can do is provide a concise API and create solid documentation. Make sure to specify the default directories for the system cert pool, proving a second argument --ca to let them give their own cert bundle. Go APIs will validate the arguments you give do give them are valid, and report reasonable errors when you don't that you can propagate to users.</p>
<p>If after that you are still intent on providing them support for their config, create a TLS troubleshooter in Go that accepts the same arguments as your program and suggest when your program fail to try running it. Avoid the urge to bundle it into your app, again I promise this is how good intentions turn into compromises :)</p>
<p>Happy coding.</p></pre>Chohmoh: <pre><p>Thanks for your opinion. The service is already running and self providing. If no certificate is given, it generates one, but you're free to configure your own key and certificate or even generate requests for a CA. The only thing missing is the verification of the chain. Wrong chains won't crash the service, it may only cause the client to display a certificate warning.</p>
<p>You won't be able to mess up the config that the service can't start. The worst thing is the fail safe with a self-signed certificate. The certificate chain check is just the icing on the cake. But I'll postpone this [again] and work on more pressing concerns.</p></pre>epiris: <pre><p>Paragraph one woulda been a good post in place of the original xy problem :-)</p></pre>
