[ipxe-devel] Proposed patch: support for SSL subjectAlternativeName certificates, two other useful features

[Alex Chernyakhovsky]

Hi all,

I found the bug that was preventing certificate validation for certs
without sAN from working. I've corrected the patchset (attached). (The bug
was that the extensions was incorrectly always being flagged as enabled
even if the parse failed).

Please let me know if you find any further issues.

Sincerely,
-Alex



On Fri, Nov 1, 2013 at 4:33 PM, Alex Chernyakhovsky <achernya at google.com>wrote:

> Can you reproduce against a public cert so that I can test with it? That
> code path should be getting called unless the extensions is being detected,
> and this seems to imply the cert claims its presence but does not have any
> values.
>
> Sincerely,
> -Alex
>
>
>
> On Fri, Nov 1, 2013 at 4:31 PM, Jarrod Johnson <jarrod.b.johnson at gmail.com
> > wrote:
>
>> So I found a bug, it's probably easy to fix but I've about burned out my
>> brain making TLS work in EFI mode.
>>
>> assert(((&cert->extensions.subject_alt_name.names))->prev != NULL) failed
>> at net/tls.c line 2449
>> assert(((&cert->extensions.subject_alt_name.names))->next != NULL) failed
>> at net/tls.c line 2449
>> assert(((&cert->extensions.subject_alt_name.names))->next->prev ==
>> ((&cert->extensions.subject_alt_name.names))) failed at net/tls.c line 2449
>> assert(((&cert->extensions.subject_alt_name.names))->prev->next ==
>> ((&cert->extensions.subject_alt_name.names))) failed at net/tls.c line 2449
>> assert((((&cert->extensions.subject_alt_name.names)->next)) != NULL)
>> failed at net/tls.c line 2449
>>
>> My cert has no alt names.
>>
>>
>> On Fri, Nov 1, 2013 at 1:10 PM, Alex Chernyakhovsky <achernya at google.com>wrote:
>>
>>> Hi,
>>>
>>> I'm still interested in getting these patches merged, so I'd appreciate
>>> review comments.
>>>
>>> Sincerely,
>>> -Alex
>>>
>>>
>>>
>>> On Tue, Oct 15, 2013 at 4:31 PM, Alex Chernyakhovsky <
>>> achernya at google.com> wrote:
>>>
>>>> Just finished testing the OCSP patch, it applies on top of the previous
>>>> 3, hence the 4/4 in the subject.
>>>>
>>>> Sincerely,
>>>> -Alex
>>>>
>>>>
>>>>
>>>> On Tue, Oct 15, 2013 at 4:16 PM, Alex Chernyakhovsky <
>>>> achernya at google.com> wrote:
>>>>
>>>>> Hi Ken,
>>>>>
>>>>> You're correct, looks like I typo'd something while preparing the
>>>>> patches. Here's an updated copy of the patchset. I've also found an issue
>>>>> in the OCSP code while doing this testing, a patch likely forthcoming.
>>>>>
>>>>> Sincerely,
>>>>> -Alex
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 15, 2013 at 2:13 PM, Ken Simon <ninkendo at gmail.com> wrote:
>>>>>
>>>>>> Alex,
>>>>>>
>>>>>> I think there's a typo in your implementation of dns_wildcard_matcher:
>>>>>>
>>>>>> + const char* first_dot = strchr (dns, '*') ;
>>>>>>
>>>>>> you probably want:
>>>>>>
>>>>>> + const char* first_dot = strchr (dns, '.') ;
>>>>>>
>>>>>> Fixing the patch in that way I was able to get wildcard certificates
>>>>>> to work with iPXE.
>>>>>>
>>>>>> --
>>>>>> Ken
>>>>>> _______________________________________________
>>>>>> ipxe-devel mailing list
>>>>>> ipxe-devel at lists.ipxe.org
>>>>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> ipxe-devel mailing list
>>> ipxe-devel at lists.ipxe.org
>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20131108/4d2142b0/attachment.htm>