Im using activex version 9.5.0.79 with ftps on port 990.
If I use following code snippet (server, logon etc is already set):-
loftp.authTls=0
loftp.authssl=0
loftp.ssl=1
loftp.RequireSSLVertVerify=1
loftp.SetSllClientCert(loClientCert)
lnSuccess=SetSslCertRequirement("ServerCN", "test.test.com")
lnSuccess=loftp.connect()
It seems to work lnsuccess=1 for the connect even if the server's SubjectCN is "fred.fred.com"
I can of course get the server certificate as per your example
https://www.example-code.com/foxpro/ftp_verifyServerCert.asp
and check it manually but wondering why the requirement wasn't honoured?
Thanks Rob,
This new build fixes the problem:
32-bit: https://chilkatdownload.com/prerelease/chilkatax-9.5.0-win32-1604.zip
This will be noted in the v9.5.0.80 release notes (and v9.5.0.80 is due out before the end of October). The above pre-release URL will not remain valid forever..
Related
I am trying to use the code given in this git repository. The code is not mine and I would like to thank honeyligo for his work!
I unfortunately can't manage to run it properly (I had to fix some compilation issues but nothing dramatic).
After setting the main.cpp to
#include <unistd.h>
#include "curlsmtp.h"
int main(){
CurlSmtp* mail = new CurlSmtp(
"MYADDRESS#gmail.com",
"MYPASSWORD",
{ "foo#yahoo.fr" },
{},
{},
{},
"it's a subject",
"hello world you aredfsf",
"smtp.gmail.com",
"465");
mail->send_mail();
sleep(3);
delete mail;
return 0;
}
it constantly returns
* Expire in 200 ms for 1 (transfer 0x558a3b95d7e0)
then fails after a timeout. The code is roughly 500 lines long and well commented but I can't figure out why it fails. I don't know much about curl but I'm looking for a way to automatically sent mails with a pdf attached to my high school students. I need to implement a c++ solution because this will be part of a larger project.
Thanks for your help!
After some testing with curl both from the CLI and in a C app using libcurl, I found the issue: gmail only accepts smtp requests if you explicitly use smtps (smtps://smtp.gmail.com).
As it's hardcoded in this curlsmtp lib to use smtp://, you either modify it (set_curl_option method) or use libcurl directly (an easy example here: https://curl.haxx.se/libcurl/c/smtp-mime.html)
Also, you either have to set up 2FA in your Google account and create an app password, or enable access for less secure apps if there is no 2FA (https://myaccount.google.com/lesssecureapps).
I am building a Rest client with cpprest-sdk to communicate with a web service. The problem is that every once in a while, after sending multiple successful requests (around 50), I get the exception:
WinHttpSendRequest: 2148074273 insufficient cache in function
Or sometimes:
ERROR_WINHTTP_SECURE_FAILURE (12175)
I tried to look for cache options in cpprest-sdk but did not find anything. Since the exceptions happens inside cpprest-sdk when I call .wait() on my task I am not sure if I can use the WINHTTP_STATUS_CALLBACK to check for more details on this error. How can I investigate deeper to find the cause of this error?
Here is my Rest request:
void MyRestClient::PostKeys(const std::string & sKek, const std::string & sKid, const std::string & sCustomerAuthenticator) {
uri_builder oBuilder(U("/keys?customerAuthenticator=") + to_string_t(sCustomerAuthenticator));
oBuilder.append_query(KEK, to_string_t(sKek));
json::value oBody;
oBody[KID] = json::value::string(to_string_t(sKid));
web::http::http_request oRequest;
oRequest.set_method(methods::POST);
oRequest.set_request_uri(oBuilder.to_uri());
oRequest.set_body(oBody);
m_oCurrentTask = oClient.request(oRequest).then([this](http_response oResponse) {
OnPostResponse(oResponse);
});
}
According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa383928(v=vs.85).aspx (4th bullet), Post requests should not be cached so I don't understand why I am getting the first exception. I also tried to disable Https caching as the 6th bullet in the link suggest, but that did not change anything.
Did anyone experienced something similar or have any insight as to what may be happening? Or is this a normal behavior and should I just retry my request when these exceptions happens?
Does your Web Service use TLS with Diffie-Hellman key exchange? If yes, you are probably seeing a bug in SChannel, which is the SSL implementation of Windows, see here for a confirmation. Unfortunately, the only available fix is an update of the Windows version on which your client is running to a recent build of Windows 10.
I'm trying to build a simple web app using Django. I'd like a minimal user model with verification using Mozilla Persona. Using Persona happens without a hitch, until the SSL certificate fails when tossing the authentication (success or failure) back to the Django app.
I know there is a lot on Stack Overflow already about SSL errors, but I haven't turned up anything that works in this case. For example, trying to use verify = False when using the requests package still produces the error.
I was able to replicate the error in a minimal example app using the default settings for a new Django project and following the boilerplate installation for django_browserid. Even if this can be hacked, it might be worth noting in either the django_browserid docs or the Persona documentation if someone knows how to remedy this annoying bug.
I've put this minimal example with instructions on GitHub.com at:
https://github.com/pedmiston/ssl_error
The actual error is, with [blob] substituted in place of the assertion.
Error while verifying assertion [blob] with audience http://localhost:8000.
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598)
I'm on OSX Mavericks.
Update: I was able to get the minimal example to pass using sigmavirus24's answer, by adding the following to my virtualenv's src/django_browserid/base.py
class RemoteVerifier(object):
"""
Verifies BrowserID assertions using a remote verification service.
By default, this uses the Mozilla Persona service for remote verification.
"""
verification_service_url = 'https://verifier.login.persona.org/verify'
requests_parameters = {
'timeout': 5,
'verify': False,
}
# ...
This is great, and it gets the minimal example to pass (and assures me that this isn't really a django_browserid or Persona error?).
However, it does just kind of by-pass the merits of the verification procedure. Now that the error has been localized, any suggestions for how to fix it?
I've been reading that there were some changes in OS X when Mavericks came around, in a switch from open_ssl to Apple's own Secure Transport engine. If this is the cause of the problem I'm having, then it might be worth knowing for others who run into a similar problem when using Mavericks.
Looking at your example app and it's sole dependency it seems your trouble is coming from this line in django_browserid. I'm not familiar with your app or django_browserid but if you can pass verify=False to https://github.com/mozilla/django-browserid/blob/66641335751b869562ba7a554e61ca56bc880257/django_browserid/base.py#L167 this should solve your problems. In other words, if you specify which Verifier you use, then it should do something like
verifier = RemoteVerifier()
verifier.requests_parameters['verify'] = False
# or
verifier.verify(verify=False)
Of course you didn't show any code where you were doing that so that could be what you meant when you said:
For example, trying to use verify = False when using the requests package still produces the error.
But I can't tell that from the code you have posted.
Using custom C++ OCI wrappers, I can successful register a CQN C++ callback-based registration, but it appears that somehow the subscription is dropped right away, behind my back. I get no call back on simple DMLs. If I try to unregister that subscription, for which register() worked just fine, I get ORA-29970: Specified registration id does not exist.
I'm running this test on a Win7 (64-bit) box, running a local 11.2.0.1.0 Oracle Server, and I connect with a C++ client app built against instantclient-11.2.0.2.0 that runs on that same machine.
I tried setting OCI_ATTR_SUBSCR_TIMEOUT explicitly to 0, to no avail.
I checked the job_queue_processes instance param to make sure it's not 0 (it's 1000).
Of course, the user/schema I'm connecting with has been granted CHANGE NOTIFICATION
I'm running out of ideas on this issue, and I would appreciate some insights on what else I could try or check.
I'm starting to wonder if CQN needs to be activated somehow. My DBA skills are close to nonexistent, this is a stock install of 11gR1 on Windows using the installer, with no special configurations or customization done at all.
Thanks, --DD
Update #1
A colleague successfully ran that same test, and he ran it using the server-provided oci.dll. I tried that (I build using instantclient, but forced the PATH at runtime: Path=D:\oracle\product\11.2.0\dbhome_1\BIN;$(Path) in VS Property Page> Debugging> Environment), and indeed the CQN test works! We still haven't figured out whether the slight version difference between client and server, or using instantclient (the Light variant by the way) vs a full client vs a server install is the real culprit.
But it is bad news that a newer instantclient does not support CQN...
Update #2
I've tried all 6 combinations of instantclient Light (65 MB) or Normal (150 MB) in versions 12.2.0.(1|2|3).0 on Win64, and none of them worked. Haven't tested the Full Client yet, nor have we tested on Linux just yet.
Environment_var cqn_env = Environment::create(OCI_EVENTS + OCI_OBJECT);
Connection_var cqn_conn = Connection::logon2(...);
Subscription sub(cqn_conn, "cqn_test", OCI_SUBSCR_NAMESPACE_DBCHANGE);
sub.set<attr::SUBSCR_CALLBACK>( &cqn_callback_func );
sub.set<attr::SUBSCR_CQ_QOSFLAGS>( OCI_SUBSCR_CQ_QOS_QUERY );
try {
sub.register_self();
} catch (const OracleException& ex) {
BOOST_REQUIRE(ex.error_code && *ex.error_code == 29972);
cerr << "\nSKIPPED: test requires CHANGE NOTIFICATION privilege" << endl;
return;
}
I want to verify an SSL certificate in Win32 using C++. I think I want to use the Cert* API so that I can get the benefit of the Windows certificate store. This is what I've come up with.
Is it correct?
Is there a better way to do this?
Am I doing anything wrong?
bool IsValidSSLCertificate( PCCERT_CONTEXT certificate, LPWSTR serverName )
{
LPTSTR usages[] = { szOID_PKIX_KP_SERVER_AUTH };
CERT_CHAIN_PARA params = { sizeof( params ) };
params.RequestedUsage.dwType = USAGE_MATCH_TYPE_AND;
params.RequestedUsage.Usage.cUsageIdentifier = _countof( usages );
params.RequestedUsage.Usage.rgpszUsageIdentifier = usages;
PCCERT_CHAIN_CONTEXT chainContext = 0;
if ( !CertGetCertificateChain( NULL,
certificate,
NULL,
NULL,
¶ms,
CERT_CHAIN_REVOCATION_CHECK_CHAIN,
NULL,
&chainContext ) )
{
return false;
}
SSL_EXTRA_CERT_CHAIN_POLICY_PARA sslPolicy = { sizeof( sslPolicy ) };
sslPolicy.dwAuthType = AUTHTYPE_SERVER;
sslPolicy.pwszServerName = serverName;
CERT_CHAIN_POLICY_PARA policy = { sizeof( policy ) };
policy.pvExtraPolicyPara = &sslPolicy;
CERT_CHAIN_POLICY_STATUS status = { sizeof( status ) };
BOOL verified = CertVerifyCertificateChainPolicy( CERT_CHAIN_POLICY_SSL,
chainContext,
&policy,
&status );
CertFreeCertificateChain( chainContext );
return verified && status.dwError == 0;
}
You should be aware of RFC3280 section 6.1 and RFC5280 section 6.1. Both describe algorithms for validating certificate paths. Even though Win32 API takes care of some things for you, it could still be valuable to know about the process in general.
Also, here’s a (in my opinion) pretty trustworthy reference: Chromium certificate verification code.
Overall, I think your code isn't incorrect. But here’s a few things I’d look into/change, if I were you:
1. Separate Common Name Validation
Chromium validates certificate common name separately from the chain. Apparently they've noticed some problems with it. See the comments for their rationale:
cert_verify_proc.win.cc:731 // Certificate name validation happens separately, later, using an internal
cert_verify_proc.win.cc:732 // routine that has better support for RFC 6125 name matching.
2. Use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT
Chromium also uses the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag instead of CERT_CHAIN_REVOCATION_CHECK_CHAIN. I actually started to looking into this before I found their code, and it reinforced my belief that you should use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT.
Even though both aforementioned RFCs specify that a self-signed trust anchor is not considered part of a chain, the documentation for CertGetCertificateChain (http://msdn.microsoft.com/en-us/library/windows/desktop/aa376078(v=vs.85).aspx) says it builds a chain up to, if possible, a trusted root certificate. A trusted root certificate is defined (on the same page) as a trusted self-signed certificate.
This eliminates the possibility that *EXCLUDE_ROOT might skip revocation checking for a non-root trust anchor (Win32 actually requires trust-anchors to be self-signed, even though it is not required by any RFCs. Though this is not officially documented).
Now, since a root CA certificate can not revoke itself (the CRL could not be signed/verified), it seems to me that these two flags are identical.
I did some googling and stumbled across this forum post: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9f95882a-1a68-477a-80ee-0a7e3c7ae5cf/x509revocationflag-question?forum=windowssecurity. A member of .NET Product Group (supposedly) claims that the flags in practice act the same, if the root is self-signed (in theory, the ENTIRE_CHAIN flag would check the root certificate for revocation if it included a CDP extension, but that can’t happen).
He also recommends to use the *EXCLUDE_ROOT flag, because the other flag could cause an unnecessary network request, if the self-signed root CA includes the CDP extension.
Unfortunately:
I can’t find any officially documented explanation on the differences between the two flags.
Even though it is likely that the linked discussion applies to the same Win32 API flags under the hood of .NET, it is not guaranteed.
To be completely sure that it’s ok to use CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT, I googled a bit more and found the Chromium SSL certificate verification code I linked to at the top of my reply.
As an added bonus, the Chromium cert_verify_proc_win.cc file contains the following hints about IE verification code:
618: // IE passes a non-NULL pTime argument that specifies the current system
619: // time. IE passes CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT as the
620: // chain_flags argument.
Not sure how they’d know this, but at this point I’d feel comfortable using CERT_CHAIN_REVOCATION_CHECK_EXCLUDE_ROOT.
3. Different Accepted Certificate Usages
I noticed Chromium also specifies 3 certificate usages instead of 1:
szOID_PKIX_KP_SERVER_AUTH,
szOID_SERVER_GATED_CRYPTO,
szOID_SGC_NETSCAPE
From what I can gather through Google, the other usages can be required by older web browsers, otherwise they can fail to establish a secure connection.
If Chromium deems fit to include these usages, I'd follow suit.
Note that if you change your code, you should also set params.RequestedUsage.dwType to USAGE_MATCH_TYPE_OR instead of USAGE_MATCH_TYPE_AND.
—
I can’t think of any other comments at the moment. But if I were you, I’d check out Chromium source myself (and maybe Firefox too) - just to be sure I haven’t missed anything.
I think the best answer depends on what exactly you are attempting to do.
I will caution you that SSL is based on the assumption that Both endpoints want a secure connection. If either endpoint isn't interested in maintaining security then there is none.
Its a trivial effort to put byte codes in your distributed code that simply returns true for this function. That's why windows moved a lot of validation into the kernel. But they didn't anticipate people running windows on virtual hardware, which makes circumventing the OS just about as trivial.
Now consider that you expect to be provided a cert from some source, but pretending that that source couldn't be provided the same information from a reliable source. And then hand it to you. So You cannot rely on certificates to "prove" anyone is anyone in particular.
The only protection gained from certificates are in preventing outsiders, not endpoints, from breaching the confidentiality of the message being transported.
Any other use is doomed to fail, and it will fail eventually with potentially catastrophic results.
Sorry for the big post. The comment section has a word limit.
The functions CertGetCertificateChain and CertVerifyCertificatePolicy go together. This part is correct.
For CertGetCertificateChain the flag can be set to any of the following three if you want to check for revocation:
CERT_CHAIN_REVOCATION_CHECK_END_CERT
CERT_CHAIN_REVOCATION_CHECK_CHAIN
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT.
Only one of them can be used, these three options cannot be ORed. Beside one of these flags you can consider how the chain should be created; using local cache or just CRL or OCSP. For these considerations read this link.
Error in executing the function or more simply if the return value is 0, it does not mean the certificate is invalid, rather you were unable to perform the operation. For error information use GetLastError(). So your logic of returning false is wrong, it is more of a case of throwing the error and let the client code decide whether to try again or go on to do other stuff.
In this link there is a section called "classify the error", please read that. Basically you should check certChainContext->TrustStatus.dwErrorStatus. Here a list of error statuses will be ORed. Please check CERT_TRUST_STATUS msdn reference. So here you can have your business logic. For example, if you find the error status of the value (CERT_TRUST_REVOCATION_STATUS_UNKNOWN | CERT_TRUST_IS_OFFLINE_REVOCATION) that certificate revocation check could not be performed, you have the option to decide what you want (let the cert go or still mark it as invalid).
So, before going to call CertVerifyCertificatePolicy you have the option to discard or already flag a validation error.
If you choose to come to CertVerifyCertificatePolicy, the chromium code is a wonderful reference regarding how to map policy_status.dwError to your error class/enum.