Intermediate certificate as CA

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Intermediate certificate as CA

Erik Seres-2
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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Ingela Andin
Hi!

2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Erik Seres-2
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

On 2018. Feb 23., at 14:53, Ingela Andin <[hidden email]> wrote:

Hi!

2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

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" <[hidden email]>
To: "Erlang-Questions Questions" <[hidden email]>
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
 

> On 2018. Feb 23., at 14:53, Ingela Andin <[hidden email][mailto:[hidden email]]> wrote: 
>
> Hi!
>
>  
> 2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email][mailto:[hidden email]]>:
>
> > 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Ingela Andin
In reply to this post by Erik Seres-2
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


2018-02-23 18:45 GMT+01:00 Erik Seres <[hidden email]>:
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

On 2018. Feb 23., at 14:53, Ingela Andin <[hidden email]> wrote:

Hi!

2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Ingela Andin
In reply to this post by Chris Rempel
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 <[hidden email]>:

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


Sent: Friday, February 23, 2018 at 9:45 AM
From: "Erik Seres" <[hidden email]>
To: "Erlang-Questions Questions" <[hidden email]>
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
 
> On 2018. Feb 23., at 14:53, Ingela Andin <[hidden email][mailto:[hidden email]]> wrote: 
>
> Hi!
>
>  
> 2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email][mailto:[hidden email]]>:
>
> > 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

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" <[hidden email]>
To: "Chris Rempel" <[hidden email]>
Cc: "Erlang-Questions Questions" <[hidden email]>
Subject: Re: [erlang-questions] Intermediate certificate as CA
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 <[hidden email]>:
 
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


Sent: Friday, February 23, 2018 at 9:45 AM
From: "Erik Seres" <[hidden email]>
To: "Erlang-Questions Questions" <[hidden email]>
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
 

> On 2018. Feb 23., at 14:53, Ingela Andin <[hidden email][mailto:[hidden email]]> wrote: 
>
> Hi!
>
>  
> 2018-02-22 17:57 GMT+01:00 Erik Seres <[hidden email][mailto:[hidden email]]>:
>
> > 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Fred Dushin
In reply to this post by Ingela Andin
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.,


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


On Feb 23, 2018, at 8:53 AM, Ingela Andin <[hidden email]> wrote:

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.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

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 

2018-03-17 16:43 GMT+01:00 Fred Dushin <[hidden email]>:
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.,


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


On Feb 23, 2018, at 8:53 AM, Ingela Andin <[hidden email]> wrote:

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.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

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

On Mar 18, 2018, at 5:58 PM, Ingela Andin <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Intermediate certificate as CA

Ingela Andin
Hi!

2018-03-19 1:35 GMT+01:00 Fred Dushin <[hidden email]>:
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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions