[erlang-questions] Intermediate certificate as CA

[Ingela Andin]

Hi!

2018-03-19 1:35 GMT+01:00 Fred Dushin <fred@REDACTED>:

> Interesting.  That entails I trust an intermediate in my certificate chain
> for connections from peers, which on the face of it doesn't seem correct,
> as it widens the collection of trusted peers unnecessarily.  Couldn't there
> be cases where you only want to trust peers from a certain CA (e.g., an
> issuing authority that is strictly below your own issuer), but not your own
> issuer?
>
>
The peer must send its chain that will identify the root. And it is checked
that you own the root.  If you decide to trust an intermediate sent by the
peer that is still a certificate sent by the peer and you are responsible
to make the decision that you trust it as a root.  Now if we have to start
guessing the chain it might be problem. Also initially it was not obvious
to me either that this was the way OpenSSL APIs worked.

It is however documented in erlang  Server side options says:

*{cacertfile, path()}*

Path to a file containing PEM-encoded CA certificates. The CA certificates
are used to build the server certificate chain and for client
authentication. The CAs are also used in the list of acceptable client CAs
passed to the client when a certificate is requested. Can be omitted if
there is no need to verify the client and if there are no intermediate CAs
for the server certificate.
client side says:

*{cacertfile, path()}*

Path to a file containing PEM-encoded CA certificates. The CA certificates
are used during server authentication and when building the client
certificate chain.




> E.g., something like
>
> CA
> +- ICA1
>    +- server
>    +- ICA2
>       +- client
>
>
> but where you only want to accept connections from ICA2.
>
> (I don't have this particular problem, but it does come to mind.)
>
> Semantically it's a little strange, too, but that can always be fixed with
> documentation.
>
> Is this because the implementation depends on OpenSSL, or just the design?
>
>

The implementation does not depend opn OpenSSL in any other way that that
it uses cryptolib from OpenSSL via the crypto application. But the API is
"insanely" backwards compatible with
older version (pre R14) that used the OpenSSL as it implementation.



Regards Ingela Erlang/OTP team - Ericsson AB


If the latter, I would suspect that changing the behavior to specify own
> certificate chains outside of the trust store would introduce nontrivial
> upgrade issues for existing users, unwitting, or otherwise.
>
> -Fred
>
> On Mar 18, 2018, at 5:58 PM, Ingela Andin <ingela.andin@REDACTED> wrote:
>
> All intermediate CA:s should be placed in the cacertfile option together
> with trusted ROOT certs, this way of configuring has been inherited from
> OpenSSL.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180319/22a1289f/attachment.htm>