EldoS | Feel safer!

Software components for data protection, secure storage and transfer


Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.
Posted: 08/24/2012 08:55:52
by Eduardo Helminsky (Standard support level)
Joined: 08/20/2010
Posts: 105

I have been using a certificate created with SHA1RSA algorithm and it is working OK. Another customer received a new certificate created with SHA256RSA algorithm. Should I inform or set something different in the https communication ? I am asking this because the communication is not working with this new certificate.

If there is something to configure how can I detect whick one I have to use ?
Posted: 08/24/2012 09:06:34
by Ken Ivanov (EldoS Corp.)


Normally the protocol itself should not be affected by the change of certificate. Could you please describe the issue in more detail:

1) Is the certificate used for server-side or client-side authentication?

2) What exactly connection problems are you getting? Is OnError event invoked? If it is, what parameters are passed to it?
Posted: 08/24/2012 12:18:06
by Eduardo Helminsky (Standard support level)
Joined: 08/20/2010
Posts: 105


Answering your questions:

1) Certificate is used for client-side authentication (and futurely to assign XML documents)

2) I have received the message "Connection lost 100354". The event OnError is not fired.

If I switch back to other certificate (SHA1RSA) then the connection to WebService works correctly.
Posted: 08/24/2012 14:24:02
by Ken Ivanov (EldoS Corp.)


Thank you for the details.

Error 100354 (0x18802, SB_HTTP_ERROR_REQUEST_NOT_COMPLETED) is returned if the component fails to get a complete HTTP response from server after sending the HTTP request. That is, SSL/TLS connection seems to be established correctly in your case, but the server then refuses to respond with a proper reply.

Basing on the symptoms, I believe that the server doesn't accept the new certificate provided by the client. A lot of HTTP servers actually behave in a similar way, simply closing the connection without any notice if the client requests a resource it has not been authorized for.

This way, now we need to establish the reason for the server not to accept the client certificate. First of all, could you please check that the certificate itself is loaded correctly on the client side and particularly that the private key is loaded as well?
Posted: 08/24/2012 15:00:08
by Eduardo Helminsky (Standard support level)
Joined: 08/20/2010
Posts: 105


I have checked the certificate with another software (made with C#) and the server connects with WebService correctly. And therefore we can discard the idea from server not accepting this new certificate because the response from WebService is according with I expect.
Posted: 08/24/2012 15:50:00
by Ken Ivanov (EldoS Corp.)

OK, so it is likely that something goes wrong on certificate loading stage. Could you please check that the certificate is loaded correctly on the client and that its PrivateKeyExists property is true?
Posted: 08/24/2012 16:23:55
by Eduardo Helminsky (Standard support level)
Joined: 08/20/2010
Posts: 105

I have checked and the certificate is loaded according the routine below and the property "PrivateKeyExists" is True.

procedure PrepararCertificado(cCertificado: String);

   function PrepareCertName(cAux: String): String;
   var cTmp: String;
        Result := '';
        while cAux <> '' do begin
           cTmp := ParseChar(cAux,'/');
           if cTmp <> '' then begin
              if Result <> '' then begin
                 Result := ', ' + Result;
              Result := cTmp + Result;

var nI: Integer;
    nK: Integer;
    cAux: String;
    IsOk: Boolean;
     if FCurrentCert = cCertificado then begin
     FCurrentCert := cCertificado;

     // Inicializa os certificados digitais


     for nI := 0 to FWinCert.Count-1 do begin
        FCert := FWinCert.Certificates[nI];

        // Verifica se encontra o certificado pelo nome
        cAux := PrepareCertName(FCert.SubjectRDN.SaveToDNString);
        IsOk := UpperCase(cAux) = UpperCase(cCertificado);

        // Verifica se encontra o certificado pelo número de série
        if not IsOk then begin
           cAux := BinaryToString(FCert.SerialNumber);
           IsOk := UpperCase(cAux) = UpperCase(cCertificado);

        if IsOk then begin
           nK := FWinCert.GetIssuerCertificate(FCert);
           while nK <> -1 do begin
              FCACert := FWinCert.Certificates[nK];
              nK := FWinCert.GetIssuerCertificate(FCACert);

     if FMemCert.Count = 0 then begin
        raise Exception.Create('O certificado "' + cCertificado + '" NÃO foi encontrado');
Posted: 08/24/2012 16:35:30
by Ken Ivanov (EldoS Corp.)


The fact that you take the certificate from a Windows system store might make some difference. At least, we should keep that in mind... Do you have a copy of the private key in file to check whether connection works if the key material is loaded *not* from system store?
Posted: 08/25/2012 07:02:41
by Eduardo Helminsky (Standard support level)
Joined: 08/20/2010
Posts: 105


I am not an expert in certificates, but... I have installed the certificate from a PFX file with the entire chain.

When you say to load *not* from system store, you mean load directly from PFX ?
Just to note I am using Windows XP and Delphi XE.

How can I save a file with private key from Internet Explorer ? And how can I load the certificates from file ?
Posted: 08/25/2012 07:57:21
by Eugene Mayevski (EldoS Corp.)

Eduardo Helminsky wrote:
When you say to load *not* from system store, you mean load directly from PFX ?

Yes, you can load certificates from the PFX. The code will look like:

var Storage : TElMemoryCertStorage;
Storage.LoadFromStreamPFX(FileStream, password);
HTTPClient.ClientCertStorage := Storage;

That's all and this should work for client-side authentication.

Sincerely yours
Eugene Mayevski
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.



Topic viewed 8595 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!