[erlang-questions] Intermediate certificate as CA

[Erik Seres]

Hello,

We are developing a custom service that uses TLS certificates.  Clients connect to that service and must present their client certificate.  The client certificates are signed by a CA managed by our service.  Our service's CA cert is in turn signed by a root cert, and not self signed.  We do not want to require the clients to hold the services intermediate cert, and so they connect just presenting their own client certificate.  However, the erlang SSL application does not seem to allow for this setup.  It seems to require that to verify the client certificate, that the service's cert is self signed (ie a root cert) or that the client provide all intermediate certs in the chain.  Is there a way to configure the service with the intermediate cert as the ca, and not require the client to also send it as part of the chain?

Thanks,

Erik

[Ingela Andin]

Hi!

2018-02-22 17:57 GMT+01:00 Erik Seres <erik...@exosite.com>:

Hello,

We are developing a custom service that uses TLS certificates.  Clients connect to that service and must present their client certificate.  The client certificates are signed by a CA managed by our service.  Our service's CA cert is in turn signed by a root cert, and not self signed.  We do not want to require the clients to hold the services intermediate cert, and so they connect just presenting their own client certificate.  

That breaks the TLS protocol. The peer in either direction should send the whole certificate chain with the exception of the ROOT certificate that is optional as the peer has to own it to be able to verify it.

 

However, the erlang SSL application does not seem to allow for this setup.  It seems to require that to verify the client certificate, that the service's cert is self signed (ie a root cert) or that the client provide all intermediate certs in the chain.  Is there a way to configure the service with the intermediate cert as the ca, and not require the client to also send it as part of the chain?

You can use the option verify_fun to customize the certificate path validation, but you would have to be careful to only accept the valid cases.

Regards Ingela Erlang/OTP team - Ericsson AB

 

Thanks,

Erik

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Erik Seres]

When you say "breaks the TLS protocol" are you referring to establishing trust through PKI or that somehow the connection security is somehow compromised?

Erik

[Chris Rempel]

Interesting. In my understanding it is perfectly valid for a server to choose to trust an intermediate certificate and validate connecting peers against it.

In fact erlang's ssl implementation provides for such a concept through partial_chain, except the implementation requires the client to send the chain up to and including the trusted intermediate. But the client should not have to send what the server considers the "trusted root".

I think the question is, why does the client have to send the trusted intermediate certificate. How does not sending it "break TLS" as you say? Do you mean it breaks erlang's implementation of TLS, or its a spec violation? I can find no indication of that.

Chris

Sent: Friday, February 23, 2018 at 9:45 AM
From: "Erik Seres" <erik...@exosite.com>
To: "Erlang-Questions Questions" <erlang-q...@erlang.org>
Subject: Re: [erlang-questions] Intermediate certificate as CA

When you say "breaks the TLS protocol" are you referring to establishing trust through PKI or that somehow the connection security is somehow compromised?
 
Erik
 

[Ingela Andin]

From the TLS RFC: 

 certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

Regards Ingela Erlang/OTP team - Ericsson AB

[Ingela Andin]

Hi!

The partial chain option lets you do the certificate path validation with an intermediate as "roo"t e.i. certificates above the trusted intermediate are not validated.  I can see that it might be practical if the server would try building the path, but that is not the way I read the RFC.

Regards Ingela Erlang/OTP team - Ericsson AB

2018-02-23 23:03 GMT+01:00 Chris Rempel <cs...@gmx.com>:

Interesting.  In my understanding it is perfectly valid for a server to choose to trust an intermediate certificate and validate connecting peers against it.

In fact erlang's ssl implementation provides for such a concept through partial_chain, except the implementation requires the client to send the chain up to and including the trusted intermediate.  But the client should not have to send what the server considers the "trusted root".

I think the question is, why does the client have to send the trusted intermediate certifoveicate. How does not sending it "break TLS" as you say?  Do you mean it breaks erlang's implementation of TLS, or its a spec violation?  I can find no indication of that.

[Chris Rempel]

It is not so much that the server should build the entire chain (though I don't see any negative to that), its that the trusted intermediate CA (just like the root) shouldn't have to be sent by the client.  Like you say, partial chain option should treat the intermediate as "root" and therefore it should be optional for the client to send it.

 

Chris

 

Sent: Saturday, February 24, 2018 at 5:59 AM
From: "Ingela Andin" <ingela...@gmail.com>
To: "Chris Rempel" <cs...@gmx.com>
Cc: "Erlang-Questions Questions" <erlang-q...@erlang.org>

[Fred Dushin]

So, I have a question about how to configure an Erlang endpoint to actually _send_ a complete certificate chain (or the chain minus the root cert, as I just consider that an optimization).

Specifically, the docs state that a (client or server) certificate is specified via:

{cert, public_key:der_encoded()} |

{certfile, path()}

where public_key:der_encoded() is a binary().

Looking at the source code, certfile may indeed contain a catenation of PEM certificates.  However, it appears that only the first is used as OwnCert, and the rest are discarded (at least when specified via a file), e.g.,

https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/ssl_config.erl#L78

https://github.com/erlang/otp/blob/OTP-20.3.1/lib/ssl/src/ssl_config.erl#L86

The spec in the docs say that the cert parameter over-rides the certfile, but the type spec for cert is a binary, not a list of binaries.  (I don't know if the OTP build enforces dialyzer specs)

With a CA hierarchy like:

CA

+- ICA1

    +- ICA2

        +- peer1

        +- peer2

        ...

I would like the server to send the client (as part of the handshake) the following certificate chain:

peer1, ICA2, ICA1 [, CA]

But in my experiments, I can only get the server to send peer1.

(I am specifically interested in server behavior, but also generally interested in client behavior, as well.)

Note that the only guarantee I have about my peer is that CA is a trusted CA; the SSL peer may have no knowledge of ICA2 or ICA1.

Thoughts?

-Fred

[Ingela Andin]

Hi!

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.

Regards Ingela Erlang/OTP team - Ericsson AB 

[Fred Dushin]

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?  

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?  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

[Ingela Andin]

Hi!

2018-03-19 1:35 GMT+01:00 Fred Dushin <fr...@dushin.net>:

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...@gmail.com> 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.