Please attach a +wininet,+crypt,+chain log.

Created attachment 40927 [details]
+wininet,+crypt,+chain log

Here you go.

All I did was start the game, login, go to store and than wineserver -k.

The problem seems to be:
trace:chain:CRYPT_BuildSimpleChain Couldn't find issuer, halting chain creation

You're connecting to https://store.eun1.lol.riotgames.com, which has the chain:
GTE CyberTrust Global Root
DigiCert High Assurance EV Root CA
DigiCert High Assurance CA-3
store.eun1.lol.riotgames.com

According to your log, when using builtin wininet, the GTE CyberTrust Global Root certificate can't be found when verifying the chain for store.eun1.lol.riotgames.com.  It's curious that using native wininet works around it, since that also uses builtin crypt32.

I'll try to have a closer look when I get a chance.

Similar looking problem with wine-git and Unity3D first run internet registration.  Native wininet doesn't help.

Created attachment 40946 [details]
rzipped +urlmon,+crypt,+secur32,+wintrust,+wininet,+winsock,+text,+seh,+chain log of clicking Register in Unity.exe startup dialog

(In reply to comment #5)
> Created attachment 40946 [details]
> rzipped +urlmon,+crypt,+secur32,+wintrust,+wininet,+winsock,+text,+seh,+chain
> log of clicking Register in Unity.exe startup dialog

Dan, from looking at your log, these look like different errors.

OK, filed that as bug 31181, sorry for the confusion.

Hang on: it does work with native wininet?  Please verify that for me.

Here's something that throws me:
trace:wininet:create_netconn using SSL connection
trace:crypt:CertOpenStore (#0002, 00000000, 00000000, 00002000, (nil))
trace:crypt:CRYPT_MemOpenStore (0, 00002000, (nil))
trace:crypt:CertCreateCertificateContext (00000001, 0x77012bb8, 1755)
trace:crypt:CryptDecodeObjectEx (0x00000001, #0002, 0x77012bb8, 1755, 0x00008000, (nil), 0x187ecd34, 0x187ecd30)
trace:crypt:CryptDecodeObjectEx returning 1
trace:crypt:CertAddCertificateContextToStore (0x6e505a28, 0x6e505b88, 00000004, 0x187ecdc8)
trace:crypt:CertDuplicateCertificateContext (0x6e505b88)
trace:crypt:CRYPT_MemAddCert (0x6e505a28, 0x6e505b88, (nil), 0x187ecdc8)
trace:crypt:CertDuplicateCertificateContext (0x6e5019d8)
trace:crypt:CertFreeCertificateContext (0x6e505b88)
trace:crypt:CertFreeCertificateContext ((nil))
trace:crypt:CertAddCertificateContextToStore returning 1
trace:crypt:CertFreeCertificateContext (0x6e505b88)
trace:wininet:netconn_verify_cert verifying L"store.eun1.lol.riotgames.com"

This shows that wininet creates a memory store, as expected, then adds a single certificate to it.  From dlls/wininet/netconnection.c:

    HCERTSTORE store = CertOpenStore(CERT_STORE_PROV_MEMORY, 0, 0,
        CERT_STORE_CREATE_NEW_FLAG, NULL);
(snip)

        struct stack_st *chain = (struct stack_st *)pX509_STORE_CTX_get_chain( ctx );

        ret = TRUE;
        for (i = 0; ret && i < psk_num(chain); i++)
        {
            PCCERT_CONTEXT context;

            cert = (X509 *)psk_value(chain, i);
            if ((context = X509_to_cert_context(cert)))
            {
                ret = CertAddCertificateContextToStore(store, context,
                        CERT_STORE_ADD_ALWAYS, i ? NULL : &endCert);
                CertFreeCertificateContext(context);
            }
        }

That is, it should get every certificate OpenSSL sees, and add each to the memory store.  Back to the log:

trace:chain:CRYPT_CheckSimpleChain checking chain with 1 elements for time (null)

Only a single certificate is found, and, looking at the log earlier, this makes sense: only a single certificate was added to the memory store.

This suggests that either the server is not including the intermediate certificates in the TLS handshake, or that OpenSSL is not reporting them.

I'm a little less sure where to go from here.  Maybe a wireshark trace of the TLS handshake could tell us whether the server is indeed sending intermediate certificates.

To clarify a little more on how lol store behaves:
With builtin wininet:
Store page does't work at all, it is always black. In user profile where there are shortcuts to buy champions, the buy button is gray and tooltip says: "Store is currently unavailable."
With native wininet:
User profile shortcuts always work (this is how I'm currently buying champions).
Store page (this is where my logs come from) loads very slowly and in parts. Looks like it's is waiting for some sort of timeout as it loads part of the store first than waits and loads another part then waits..... Sometimes it loads immediately. But it does eventually start to work.

Should I post logs from loading user profile (shortcuts to store)? I think it still needs to connect to the store, but without loading the page.

I will do wireshark traces when I come to my home computer (probably not today).

(In reply to comment #9)
> To clarify a little more on how lol store behaves:
> With builtin wininet:
> Store page does't work at all, it is always black. In user profile where there
> are shortcuts to buy champions, the buy button is gray and tooltip says: "Store
> is currently unavailable."
> With native wininet:
> User profile shortcuts always work (this is how I'm currently buying
> champions).
> Store page (this is where my logs come from) loads very slowly and in parts.
> Looks like it's is waiting for some sort of timeout as it loads part of the
> store first than waits and loads another part then waits..... Sometimes it
> loads immediately. But it does eventually start to work.
> 
> Should I post logs from loading user profile (shortcuts to store)? I think it
> still needs to connect to the store, but without loading the page.
> 
> I will do wireshark traces when I come to my home computer (probably not
> today).

I can verify that for me it throws Unknown CA in wireshark and when I look at the Certificate part of the handshake it shows that only the lq.na1.lol.riotgames.com cert is passed for the store connection.  For the login connection, the whole chain is sent, I suppose the store assumes that windows caches the chains (could this have something to do with wininet complaining that it doesn't handle persistent cookies?) but it seems maybe wine doesn't?

I can attach a pcap if someone needs, but I think I described the important bits well enough here.  Also, if you hack the source to say "sure, that cert is fine, why not?" it still doesn't work.  The server throws Encrypted Alert later, implying that the client encrypted something wrong (or rather, that the client failed to extract something it needed from the cert?).

Sorry to just barge in here with my observations, but I've been dissecting wine source code every day after work this week, Sunday.  It's wearing me down :(

Perfect, thanks for the details. (And I'm sorry it's wearing you down.)

There's a bug having to do with secur32 and certificate caching, bug 27168, and I wouldn't be surprised if there's a similar bug with wininet. You could have a look if attachment 36923 [details] has any impact.

I'll have another look at the log in the meanwhile to see if there's anything that sticks out.

(In reply to comment #11)
> Perfect, thanks for the details. (And I'm sorry it's wearing you down.)
> 
> There's a bug having to do with secur32 and certificate caching, bug 27168, and
> I wouldn't be surprised if there's a similar bug with wininet. You could have a
> look if attachment 36923 [details] has any impact.
> 
> I'll have another look at the log in the meanwhile to see if there's anything
> that sticks out.

I can provide pcaps and logs if needed, just let me know!  (also, running with lots of logging on is SO SLOW)

(In reply to comment #11)
> Perfect, thanks for the details. (And I'm sorry it's wearing you down.)
> 
> There's a bug having to do with secur32 and certificate caching, bug 27168, and
> I wouldn't be surprised if there's a similar bug with wininet. You could have a
> look if attachment 36923 [details] has any impact.
> 
> I'll have another look at the log in the meanwhile to see if there's anything
> that sticks out.

That patch from 36923 doesn't help. Nothing interesting in logs still one cert and chain validation still fails.

Could someone post a +crypt,+chain log with native wininet in use instead?  I'm curious to see what it's doing differently.

To further elaborate on one hypothesis: the app specifies INTERNET_FLAG_KEEP_CONNECTION to HttpOpenRequest; I wonder if, in native, this implies that only a single connection is opened, so the first connection that provides all the required certificates is the only one made?

A second hypothesis: the second HttpOpenRequest, which fails with builtin wininet, specifies INTERNET_FLAG_NO_UI in addition to INTERNET_FLAG_KEEP_CONNECTION, and I wonder if that's intended to suppress certain failures.

Created attachment 40999 [details]
+chain,+crypt native wininet

http://bugs.winehq.org/attachment.cgi?id=40999

Log was too large (~340k lines) so I did tail -n200k.  I can do tail -f on the log as it's being created to get just the part when I try to use the store if that would be preferable.  Alternatively (you probably already know this) just grep for lq.store.na1.lol.riotgames.com or something to that effect.

Happy sleuthing, and thanks in advance if you solve the issue!

Created attachment 41000 [details]
Patch: Mask error when INTERNET_FLAG_NO_UI is specified

Thanks.  Interesting: in your log, I still see:

trace:chain:CRYPT_BuildSimpleChain Couldn't find issuer, halting chain creation
trace:crypt:CRYPT_CheckSimpleChain a67a62checking chain with 1 elements for time (null)

That suggests that my hunch about wininet suppressing some errors might be correct, rather than that crypt32 is at fault.  Following that hunch, does the attached patch help?

(In reply to comment #18)
> Created attachment 41000 [details]
> Patch: Mask error when INTERNET_FLAG_NO_UI is specified
> 
> Thanks.  Interesting: in your log, I still see:
> 
> trace:chain:CRYPT_BuildSimpleChain Couldn't find issuer, halting chain creation
> trace:crypt:CRYPT_CheckSimpleChain a67a62checking chain with 1 elements for
> time (null)
> 
> That suggests that my hunch about wininet suppressing some errors might be
> correct, rather than that crypt32 is at fault.  Following that hunch, does the
> attached patch help?

With that patch I still see Unknown CA, and also the login shows "server busy" on the first try but works on the second.

Created attachment 41001 [details]
+crypt,+chain

(In reply to comment #18)
> Created attachment 41000 [details]
> Patch: Mask error when INTERNET_FLAG_NO_UI is specified
> 
> Thanks.  Interesting: in your log, I still see:
> 
> trace:chain:CRYPT_BuildSimpleChain Couldn't find issuer, halting chain creation
> trace:crypt:CRYPT_CheckSimpleChain a67a62checking chain with 1 elements for
> time (null)
> 
> That suggests that my hunch about wininet suppressing some errors might be
> correct, rather than that crypt32 is at fault.  Following that hunch, does the
> attached patch help?

http://bugs.winehq.org/attachment.cgi?id=41001

tail -n300k for this one to make it small enough.  Unknown CA as before, and login took 2 tries (first one said "Server Busy"

Still live as before, however now the game client itself will show a "There was a problem with the certificate.  Continue?" Yes/No prompt.

(In reply to comment #22)
> Still live as before, however now the game client itself will show a "There was
> a problem with the certificate.  Continue?" Yes/No prompt.

Commit ba4278a73502916f002e2e81100659f8f632dbc3 is likely to fix the original problem, so it's probably another bug. Please attach new wininet,crypt,chain log.

Attaching required logs (loldebug.txt). Log consists of entire log from opening launcher up until the store is opened and a black screen is displayed. The log ends after idling on the store black screen for about a minute. I'm using latest git wine, no additional patches.

Created attachment 46251 [details]
Store black screen logs, vanilla wine from git 10/10/13

Added incorrect logs last time (oops)

Gzipped and made correct ones, +wininet, +crypt, +chain

apparently too big to upload here so here's my link: http://hitechnetwork.net.au/lol2.txt.gz

I believe this bug has been fixed. I am using builtin wininet and the store works just fine.

Matej Spindler, is the problem resolved for you as well?

Can confirm that the store seems to be working correctly for me now with the version from AUR "wine-lol 1.7.1-1".  Thought I'd chime in since I commented here before when it wasn't.  Not sure what prompted the change, though, but before it seemed the cert they used was expired, prompting gnutls to not accept it...has that changed?  Was I mistaken about that?

Anyway, working now.  Just chiming in.  Cheers.

Yes it's working now.

BTW, Ryan, according to your logs, you're still using native wininet.

Closing bugs fixed in 1.7.13.