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 <acher...@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 < > crackerjackm...@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 <acher...@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 <acher...@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 < >>>> acher...@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.john...@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 < >>>>>> acher...@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 < >>>>>>> acher...@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 < >>>>>>>> acher...@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 <ninke...@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@lists.ipxe.org >>>>>>>>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ipxe-devel mailing list >>>>>>> ipxe-devel@lists.ipxe.org >>>>>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> ipxe-devel mailing list >>> ipxe-devel@lists.ipxe.org >>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >>> >>> >> >> _______________________________________________ >> ipxe-devel mailing list >> ipxe-devel@lists.ipxe.org >> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >> >> > > _______________________________________________ > ipxe-devel mailing list > ipxe-devel@lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel > >
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
