Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Http Request Replacement Ax-DLL SetClientCertificate #47

Open
Docent24 opened this issue May 17, 2024 · 13 comments
Open

Http Request Replacement Ax-DLL SetClientCertificate #47

Docent24 opened this issue May 17, 2024 · 13 comments

Comments

@Docent24
Copy link

Docent24 commented May 17, 2024

Hi.
I've tried to use Http Request dll and faced trouble with SetClientCertificate. Default location for cert is "CURRENT_USER\MY" and i have valid cert there. I got the error (8009200b): Не удается найти сертификат и закрытый ключ для расшифровки ("Key not found" in eng, i think)

Standard WinHttp.WinHttpRequest.5.1 works fine with that cert.
image

When i try to use the wrong cert name - i got different error: 80072f89 - Предоставлен недопустимый сертификат ("certificate invalid"), so i assume i specified the path to the cert correctly.

@wqweto
Copy link
Owner

wqweto commented May 17, 2024

This should be a supported use case. Is there some kind of SmartCard device (e.g. YubiKey) involved?

Which URL are you trying to access?

@Docent24
Copy link
Author

Docent24 commented May 17, 2024

Is there some kind of SmartCard device (e.g. YubiKey) involved?

No, only certificate is needed for the connection.

Which URL are you trying to access?

https://mc.api.sberbank.ru/prod/tokens/v3/oauth

@wqweto
Copy link
Owner

wqweto commented May 17, 2024

Just pushed some fixes in commit e11373f -- try downloading latest HttpRequest.zip from Releases section.

Btw, if you only have a single certificate issued by api.sberbank.ru currently registered in your CURRENT_USER\MY certificate store then you don't need the SetClientCertificate call as the class will try to auto-locate it using authorities (root certificates) from server sent certificate request.

Another option to try is using certificate thumbprint instead of common/friendly name like this: SetClientCertificate "68b5220077de8bbeaed8e1c2540fec6c16b418a8"

image

@Docent24
Copy link
Author

Actually, with the last version problem on Win 10 x64 is fixed. Well done!

But, on Windows 7 x64 i got another err message:

cHttpRequest.SetClientCertificate
pvPkiExportRsaPrivateKey.CryptEncodeObjectEx: Automation errorThe system cannot find the file specified. 

Btw, if you only have a single certificate issued

Thanks for the tip, but i have multiple certs =(

Another option to try is using certificate thumbprint

Thumbprint option works in Win 10 x64, on Win 7 i got 80072f89 - Предоставлен недопустимый сертификат ("certificate invalid") error

@wqweto
Copy link
Owner

wqweto commented May 18, 2024

Thumbprint option works in Win 10 x64, on Win 7 i got 80072f89

Just fixed finding certificates by hash under Win7 in commit faa1313 and updated HttpRequest.zip.

The automation error in pvPkiExportRsaPrivateKey should be fixed in the same commit too.

@Docent24
Copy link
Author

Yes, you nailed it! Everything works as expected on both systems. Thanks alot!

@Docent24
Copy link
Author

Docent24 commented May 18, 2024

From time to time i got error: -2147221504 (80040000): The revocation status of the certificate or one of the certificates in the certificate chain is unknown with that server, but not all the time and it seems like only on Win7. Option WinHttpRequestOption_EnableCertificateRevocationCheck fixes that, but with std WinHttp.WinHttpRequest control i don`t have this error if the option is on.

But i think this topic is the case for another issue =)

Once again, thank you for support, quick fix and the whole project. It's incredible!

@wqweto
Copy link
Owner

wqweto commented May 18, 2024

From time to time i got error: -2147221504 (80040000): The revocation status of the certificate or one of the certificates in the certificate chain is unknown with that server, but not all the time and it seems like only on Win7

I'll probably have to tweak it to default to not checking revocation on Win7 as it becomes more and more unsupported because OS probably cannot access revocation list servers securely i.e. Schannel is failing to connect to new/upgraded CRL endpoints.

Edit: Just did this in commit 60c578e and it got a bit faster establishing TLS session under Win7 as a result.

@Docent24
Copy link
Author

Docent24 commented May 18, 2024

Everything works as expected on both systems.

Hm, after further testing i faced another issue, unfortunately. On Windows 10, when i tried to connect to https://mc.api.sberbank.ru/prod/tokens/v3/oauth with cert, i got hang on .Send command. No problem with other connections so far. On Windows 7 - works fine. Version before faa1313 - works fine on Win10

@wqweto
Copy link
Owner

wqweto commented May 18, 2024

There are timeouts you can setup with SetTimeouts. By default will wait 30 seconds on receive before raising timeout error.

Another option is to use the class asynchronously and wait for OnResponseFinished event or call WaitForResponse at any point in time.

@Docent24
Copy link
Author

Docent24 commented May 18, 2024

Let me add some details,
I try to use HTTP Request ax dll with VBA-Web solution (mostly for some strong security TLS 1.2 support for Windows 7).
So, within VBA-Web, lets say, "framework" - there are timeouts configured. In my case it's 15 sec. Also Open with Async is used.

Now i got problem only in one case so far: open with cert, provided by SetClientCertificate on Windows 10.
I got stuck on .Send and never reach next .WaitForResponse statement.

By the way, with your ax i got many timeouts error with default VBA-Web WaitForResponse setting, so i set it to 1 sec.

Still, i got no propblem with WinHttp.WinHttpRequest.5.1 and version before faa1313

@wqweto
Copy link
Owner

wqweto commented May 18, 2024

Yes, this seems to be a regression in faa1313 which prevented using CNG containers for certificate private keys (which failed export under Win7 and had to be abandoned) but standard Crypto API keys cannot use PSS padding for signatures so client certificate signatures for your endpoint failed silently which revealed another bug which caused an infinite loop in a code path less travelled -- what an adventure! :-))

Anyway in commit 7fca23a CNG containers are back but this time private keys are not exported at all so this prevents Win7 from choking and allows using PSS padding for client certificates again. HttpRequest.zip updated with latest build.

@Docent24
Copy link
Author

I've done some tests and all seems to work as expected.

Once again, i can't thank you enough for this project. TLS and work with certs is quite complex thing and your knowledge of the entire topic is amazing. Speed of resolving bugs is just out of this world =)

Best wishes. Vladimir, and have a nice weekend!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants