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

Alex Chernyakhovsky achernya at google.com
Mon Mar 24 19:45:43 UTC 2014


Which assert did you hit? Could you please send an updated link to your
patchset? I'm happy to rebase mine to include fixes to make your
development easier.

Sincerely,
-Alex



On Mon, Mar 24, 2014 at 3:43 PM, Jarrod Johnson
<jarrod.b.johnson at gmail.com>wrote:

> I still hit the assert I had mentioned previously.  I avoid the assert by
> moving the 'if alt_name.present' in tls_validator_name such that it doesn't
> attempt the 'list_for_each_entry' unless that is true.
>
>
> On Mon, Nov 25, 2013 at 2:12 PM, Alex Chernyakhovsky <achernya at google.com>wrote:
>
>> Hi,
>>
>> Are there any other comments or concerns with this patchset? I'd love to
>> see it merged.
>>
>> Sincerely,
>> -Alex
>>
>>
>>
>> On Tue, Nov 12, 2013 at 12:08 PM, Kevin Landreth <
>> crackerjackmack at gmail.com> wrote:
>>
>>> This is working great for me using a StartCom Class 2 wildcard
>>> certificate with alternate names.  I only applied patches 1 and 4 though.
>>>  Seems like patches 2 and 3 are unrelated to the SSL parts ?  I did not
>>> test with a non-wildcard, non-alternate name cert.
>>>
>>> Tested on master with this build
>>> CA: https://www.startssl.com/certs/ca.pem &
>>> https://www.startssl.com/certs/sub.class2.client.ca.pem
>>> make -s EMBED=~/work/media.ipxe
>>> TRUST=~/work/trust/ca.pem,~/work/trust/sub.class2.server.ca.pem
>>>
>>> media.ipxe:
>>> #!ipxe
>>> dhcp
>>> chain https://cdn.ubooty.org/bootstrap.ipxe
>>>
>>> At any rate, thank you for this.
>>>
>>> - Kevin Landreth
>>>
>>> On Tue, Nov 12, 2013 at 9:53 AM, Alex Chernyakhovsky <
>>> achernya at google.com> wrote:
>>>
>>>> Whoops, mail client ate the attachment. Should be attached (really!)
>>>> this time.
>>>>
>>>> Sincerely,
>>>> -Alex
>>>>
>>>>
>>>> On Fri, Nov 8, 2013 at 3:45 PM, Alex Chernyakhovsky <
>>>> achernya at google.com> wrote:
>>>>
>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20140324/562ee598/attachment.htm>


More information about the ipxe-devel mailing list