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

Tue Mar 25 17:28:38 UTC 2014

Here's where I added IPv4 subjectaltname:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/e4a9069fe792f702d24bf725586fb209f8faf541

Here's where I avoid hitting assert should I not have a subjectaltname
field:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/e217322f39ae18f0a9976d8c23bb1661f9966d5f

On Mon, Mar 24, 2014 at 3:45 PM, Alex Chernyakhovsky <achernya at google.com>wrote:

> 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/20140325/04ad12cc/attachment.htm>