[prev in list] [next in list] [prev in thread] [next in thread]
List: strongswan-users
Subject: Re: [strongSwan] IPSEC/l2TP Chrome OS
From: Ilan Caspi <ilan.caspi () gmail ! com>
Date: 2015-02-17 18:14:38
Message-ID: CAE6mfiTLT16Rywozdk5SSd+vSjQpQ8PqT=93jhVQ8qZuEDghiQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks Tobias,
I've submitted a bug to the chromium project
https://code.google.com/p/chromium/issues/detail?id=459261
Cheers,
Ilan
On Fri, Feb 13, 2015 at 1:17 AM, Tobias Brunner <tobias@strongswan.org>
wrote:
> Hi Ilan,
>
> Thanks for the log. Here we see the reason for that INFORMATIONAL request:
>
> > 2015-02-12T10:22:25.578064-08:00 charon[2428]: 09[ENC] payload of type
> CERTIFICATE_V1 more than 2 times (3) occurred in current message
> > 2015-02-12T10:22:25.578096-08:00 charon[2428]: 09[IKE] message
> verification failed
> > 2015-02-12T10:22:25.578114-08:00 charon[2428]: 09[ENC] generating
> INFORMATIONAL_V1 request 4041721436 [ HASH N(PLD_MAL) ]
> > 2015-02-12T10:22:25.578130-08:00 charon[2428]: 09[NET] sending packet:
> from 10.0.1.186[4500] to 162.243.137.92[4500] (68 bytes)
> > 2015-02-12T10:22:25.578147-08:00 charon[2428]: 09[IKE] ID_PROT response
> with message ID 0 processing failed
>
> So the client doesn't like the three certificates (two intermediate CAs
> and server) sent by the server, as seen here:
>
> > 09[IKE] sending end entity cert "CN=
> do-c6176704.san-francisco-1.pertinoipsec.dev.pertino.com, OU=DEV, O=
> pertino.com, C=US"
> > 09[IKE] sending issuer cert "CN=Pertino Dev Issuing CA G1, O=Pertino,
> C=US"
> > 09[IKE] sending issuer cert "CN=Pertino Dev Intermediate CA G1,
> O=Pertino, C=US"
> > 09[ENC] generating ID_PROT response 0 [ ID CERT CERT CERT SIG ]
>
> We actually changed this limit a while ago with [1], which was included
> in 5.1.1. Apparently, Chrome OS still uses an older version of
> strongSwan. You might want to file a bug report at [2].
>
> If the client allows you to configure the server certificate instead of
> a CA certificate you could do so and then use `leftsendcert=never` on
> the sever to avoid any certificate getting sent to the client.
>
> It that's not the case you could try to use one of the intermediate CA
> certificates as trust anchor and install that on the client instead of
> the root CA certificate. Then remove the root certificate and/or the
> intermediate certificate closer to the root from ipsec.d/cacert on the
> server. That should reduce the number of CERT payloads sent to the
> client to one or two.
>
> Regards,
> Tobias
>
> [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d489e7557
> [2] https://code.google.com/p/chromium/issues/list
>
>
--
Ilan
[Attachment #5 (text/html)]
<div dir="ltr">Thanks Tobias,<div><br></div><div>I've submitted a bug to the \
chromium project <a href="https://code.google.com/p/chromium/issues/detail?id=459261"> \
https://code.google.com/p/chromium/issues/detail?id=459261</a></div><div><br></div><div>Cheers,</div><div>Ilan</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 1:17 AM, \
Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" \
target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Ilan,<br> <br>
Thanks for the log. Here we see the reason for that INFORMATIONAL request:<br>
<span class=""><br>
> 2015-02-12T10:22:25.578064-08:00 charon[2428]: 09[ENC] payload of type \
CERTIFICATE_V1 more than 2 times (3) occurred in current message<br> > \
2015-02-12T10:22:25.578096-08:00 charon[2428]: 09[IKE] message verification \
failed<br> > 2015-02-12T10:22:25.578114-08:00 charon[2428]: 09[ENC] generating \
INFORMATIONAL_V1 request 4041721436 [ HASH N(PLD_MAL) ]<br> > \
2015-02-12T10:22:25.578130-08:00 charon[2428]: 09[NET] sending packet: from \
10.0.1.186[4500] to 162.243.137.92[4500] (68 bytes)<br> > \
2015-02-12T10:22:25.578147-08:00 charon[2428]: 09[IKE] ID_PROT response with message \
ID 0 processing failed<br> <br>
</span>So the client doesn't like the three certificates (two intermediate \
CAs<br> and server) sent by the server, as seen here:<br>
<span class=""><br>
> 09[IKE] sending end entity cert "CN=<a \
href="http://do-c6176704.san-francisco-1.pertinoipsec.dev.pertino.com" \
target="_blank">do-c6176704.san-francisco-1.pertinoipsec.dev.pertino.com</a>, OU=DEV, \
O=<a href="http://pertino.com" target="_blank">pertino.com</a>, C=US"<br> > \
09[IKE] sending issuer cert "CN=Pertino Dev Issuing CA G1, O=Pertino, \
C=US"<br> > 09[IKE] sending issuer cert "CN=Pertino Dev Intermediate CA \
G1, O=Pertino, C=US"<br> > 09[ENC] generating ID_PROT response 0 [ ID CERT \
CERT CERT SIG ]<br> <br>
</span>We actually changed this limit a while ago with [1], which was included<br>
in 5.1.1. Apparently, Chrome OS still uses an older version of<br>
strongSwan. You might want to file a bug report at [2].<br>
<br>
If the client allows you to configure the server certificate instead of<br>
a CA certificate you could do so and then use `leftsendcert=never` on<br>
the sever to avoid any certificate getting sent to the client.<br>
<br>
It that's not the case you could try to use one of the intermediate CA<br>
certificates as trust anchor and install that on the client instead of<br>
the root CA certificate. Then remove the root certificate and/or the<br>
intermediate certificate closer to the root from ipsec.d/cacert on the<br>
server. That should reduce the number of CERT payloads sent to the<br>
client to one or two.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d489e7557" \
target="_blank">http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d489e7557</a><br>
[2] <a href="https://code.google.com/p/chromium/issues/list" \
target="_blank">https://code.google.com/p/chromium/issues/list</a><br> <br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature">Ilan</div> </div>
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic