Search the Community

Hi, Using D12. I've just started playing with openssl, and thought how hard would it be calling the openssl libcrypto-3.dll. Its a learning exercise more than anything. I'm trying to make a self signed X509 certifcate via the dll rather than the command line. I havent played with returning struct from a C dll before. Currently some of the call including the X509_set_version(Cert, 2) call appears to work (not throw an error) but the X509_set_serialNumber(Cert, 1) and the X509_set_pubkey(Cert, PKey) throws an exceptions. can I use a pointer to hold the return value to X509_new function? can I use that pointer to pass into the other function? or do I have to have a record that the struct is copied back into and then use that (I hope not) TIA Const LIB_CRYPTO = 'libcrypto-3.dll'; type PX509 = Pointer; PBIO = Pointer; PEVP_PKEY = Pointer; PEVP_MD = Pointer; PX509_NAME = Pointer; // OpenSSL X509 functions function X509_new: PX509; cdecl; external LIB_CRYPTO name 'X509_new'; procedure X509_free(cert: PX509); cdecl; external LIB_CRYPTO name 'X509_free'; function X509_set_version(cert: PX509; version: Integer; ): Integer; cdecl; external LIB_CRYPTO name 'X509_set_version'; function X509_set_serialNumber(cert: PX509; serial: Integer; ): Integer; cdecl; external LIB_CRYPTO name 'X509_set_serialNumber'; function X509_set_subject_name(cert: PX509; name: PX509_NAME): Integer; cdecl; external LIB_CRYPTO name 'X509_set_subject_name'; function X509_set_issuer_name(cert: PX509; name: PX509_NAME): Integer; cdecl; external LIB_CRYPTO name 'X509_set_issuer_name'; function X509_set_pubkey(cert: PX509; pkey: PEVP_PKEY): Integer; cdecl; external LIB_CRYPTO name 'X509_set_pubkey'; function X509_sign(cert: PX509; pkey: PEVP_PKEY; md: PEVP_MD): Integer; cdecl; external LIB_CRYPTO name 'X509_sign'; // Key management functions function EVP_PKEY_new: PEVP_PKEY; cdecl; external LIB_CRYPTO name 'EVP_PKEY_new'; procedure EVP_PKEY_free(pkey: PEVP_PKEY); cdecl; external LIB_CRYPTO name 'EVP_PKEY_free'; function EVP_PKEY_generate_key: PEVP_PKEY; cdecl; external LIB_CRYPTO name 'EVP_PKEY_keygen'; function CreateSelfSignedCert(CommonName, Country, Organization, OrganizationalUnit: string; ValidDays: Integer; out ACertificate, APrivateKey: TBytes): Boolean; implementation function CreateSelfSignedCert(CommonName, Country, Organization, OrganizationalUnit: string; ValidDays: Integer; out ACertificate, APrivateKey: TBytes): Boolean; var Cert: PX509; PKey: PEVP_PKEY; Name: PX509_NAME; Digest: PEVP_MD; CertBio, KeyBio: PBIO; begin Result := False; Cert := X509_new; if Cert = nil then Exit; try // Set certificate version to v3 as its self signed if X509_set_version(Cert, 2) <> 1 then Exit; // Set serial number if X509_set_serialNumber(Cert, 1) <> 1 then Exit; // Generate a new key PKey := EVP_PKEY_new; if PKey = nil then Exit; try PKey := EVP_PKEY_generate_key(); if PKEY = nil then Exit; // Set public key for the certificate if X509_set_pubkey(Cert, PKey) <> 1 then Exit; // Set certificate subject and issuer (self-signed, so both are the same) // Set validity period // Sign the certificate // Write the certificate to TBytes Result := True; finally EVP_PKEY_free(PKey); end; finally X509_free(Cert); end; end;

Hello everyone, I'm working on a Delphi project that requires signing a request signature with RSASSA-PSS algorithm. In my implementation, I initialize the signing context with EVP_DigestSignInit using SHA-256. However, when I attempt to set the salt length with EVP_PKEY_CTX_set_rsa_pss_saltlen(PSSCtx, 32), it consistently returns an error. I'm using the OverByteIcsLIBEAY.pas functions. Params I need to use for the signature: Hash algorithm: SHA-256 Mask generation function: MGF1 Mask generation algorithm: SHA-256 Salt length: 32 bytes (= 256 bits, same as the hash length) Trailer field: 1 Has anyone here encountered similar issues with RSASSA-PSS in OpenSSL, particularly with setting the salt length? Any advice on handling this setup in Delphi would be greatly appreciated! Thanks in advance! function TIsabelData.SignData(const AData: TBytes; APrivateKey: PEVP_PKEY): string; var SignCtx: PEVP_MD_CTX; PSSCtx: PEVP_PKEY_CTX; Sig: TBytes; SigLen: Cardinal; ErrCode: Cardinal; begin if EVP_PKEY_base_id(APrivateKey) <> EVP_PKEY_RSA then raise Exception.Create('The provided key is not an RSA key'); SignCtx := EVP_MD_CTX_create; PSSCtx := nil; try if EVP_DigestSignInit(SignCtx, @PSSCtx, EVP_sha256, nil, APrivateKey) <> 1 then raise Exception.Create('Error initializing digest sign'); if EVP_PKEY_CTX_set_rsa_padding(PSSCtx, RSA_PKCS1_PSS_PADDING) <= 0 then raise Exception.Create('Error setting RSA PSS padding'); if EVP_PKEY_CTX_set_rsa_pss_saltlen(PSSCtx, 32) <= 0 then begin ErrCode := ERR_get_error; raise Exception.Create('Error setting RSA PSS salt length: ' + string(ERR_reason_error_string(ErrCode))); end; if EVP_PKEY_CTX_set_rsa_mgf1_md(PSSCtx, EVP_sha256) <= 0 then raise Exception.Create('Error setting MGF1 to SHA256'); if EVP_DigestSignUpdate(SignCtx, @AData[0], Length(AData)) <> 1 then raise Exception.Create('Error updating digest sign'); SigLen := 0; if EVP_DigestSignFinal(SignCtx, nil, @SigLen) <> 1 then raise Exception.Create('Error finalizing digest sign'); SetLength(Sig, SigLen); if EVP_DigestSignFinal(SignCtx, @Sig[0], @SigLen) <> 1 then raise Exception.Create('Error finalizing digest sign'); Result := TNetEncoding.Base64.EncodeBytesToString(Sig); finally EVP_MD_CTX_free(SignCtx); EVP_PKEY_CTX_free(PSSCtx); end; end;

Hello, I made an application which must communicate using mail, socket and FTP. In that way, i found ICS really incredible for my use and easy to implement. Unfortunately, i come into a problem. I need to use SSHv2 to access some FTP (not owned by me) and ICS only support FTP, SSHv1, FTPS. I had another composent before which is "libssh2_delphi" a wrapper for "libssh2.dll". This "libssh2.dll" use an older version of OpenSSL which is "libcrypto-1_1-x64.dll" (vesion 1.1.1g) while ICS use "libssl-3-x64.dll" and "libcrypto-3-x64.dll" (both version 3.3.1). Do you think i can use ICS and this SSH2 wrapper which use different .dll? Doesn't load multiple openssl dlls in my application can cause unexpected behavior? Thank you for your time.

After finishing and testing the configuration to have TLS 1.2 on TIdFTPServer I was asked to add OpenSSL and TLS 1.2 also on the API server (based on TIdTCPServer TCP/IP communication). Unfortunately when I set Active to True, and IdSSLOpenSSL.InitContext is called, in the CiperList settings step it always returns error = 1 and I don't understand what I am doing wrong: if StatusInfoOn then begin SSL_CTX_set_info_callback(fContext, InfoCallback); end; //if_SSL_CTX_set_tmp_rsa_callback(hSSLContext, @RSACallback); if fCipherList <> '' then begin {Do not Localize} error := SSL_CTX_set_cipher_list(fContext, {$IFDEF USE_MARSHALLED_PTRS} M.AsAnsi(fCipherList).ToPointer {$ELSE} PAnsiChar( {$IFDEF STRING_IS_ANSI} fCipherList {$ELSE} AnsiString(fCipherList) // explicit cast to Ansi {$ENDIF} ) {$ENDIF} ); end else begin // RLebeau: don't override OpenSSL's default. As OpenSSL evolves, the // SSL_DEFAULT_CIPHER_LIST constant defined in the C/C++ SDK may change, // while Indy's define of it might take some time to catch up. We don't // want users using an older default with newer DLLs... (* error := SSL_CTX_set_cipher_list(fContext, {$IFDEF USE_MARSHALLED_PTRS} M.AsAnsi(SSL_DEFAULT_CIPHER_LIST).ToPointer {$ELSE} SSL_DEFAULT_CIPHER_LIST {$ENDIF} ); *) error := 1; end; Server code: https://pastebin.com/z82zhGyQ I am using the latest Indy sources from the git repository. I thank you in advance for any suggestions Best Regards Silverio

With this new year, it was time to make a mORMot 2 release. We went a bit behind the SQlite3 engine, and we added some nice features. 😎 Main added features: - OpenSSL 3.0/3.1 direct support in addition to 1.1 (with auto-switch at runtime) - Native X.509, RSA and HSM support - mget utility (wget + peer cache) Main changes: - Upgraded SQLite3 to 3.44.2 - Lots of bug fixes and enhancements (especially about cryptography and networking) - A lot of optimizations, so that we eventually reached in top 12 ranking of all frameworks tested by TFB https://github.com/synopse/mORMot2/releases/tag/2.2.stable 🙂

You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday... Most sensible options are to switch to 3.0 or 3.1 as soon as possible. But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do we need to use? 😮 I just published a blog article about this, and also how we tried to leverage any incompatibility issue within the mORMot OpenSSL layer: https://blog.synopse.info/?post/2023/09/08/End-Of-Live-OpenSSL-1.1-vs-Slow-OpenSSL-3.0

Moving My application to D 11.2 Android 13 and android 64 bit on a Pixel 4 XL. get a message that openSSL fails to load Have put libcrypto.so and libssl.so for OpenSSL 1.0.2g Android\Android\armeabi-v7a in deployment to .\assets\internal\ ( this worked on the Android32 bit app D 10.4) these were downloaded from the indy sockets/ Openssl binarys using IdSSLOpenSSLHeaders.WhichFailedToLoad() I get the result "Failed to load /data/user/0/com.embarcadero.<MyApp>/files/libcrypto.so." Tried dropping them in the above directory but ended with the same result not clear if I have the wrong versions of the *.so files ( I think the pixel processor is armabi-V8) or whether I am placing the files in the wrong folder at Deployment have found some notes in my search's that perhaps I Should " statically build OpenSSL directly into your app binary" if this is necessary can anyone point me to some notes on how to achive this thanks in advance Ian

The difficulties when trying to use OpenSSL filters on a DataSnap application with an Android client have numbers of entries in various forums that go back a number of years. To summarize the problem: 1. Create a DataSnap server that specifies a filter of RSA, in my case using Delphi 11 Update 2, running on a Windows server as a service. 2. Create a DataSnap client that is deployed to an Android device, in my case a Samsung SD-9 with an ARM64-v8a instruction set running Android 10 3. The client application crashes because it is unable to load a required OpenSSL module. I have tried a number of solutions that are discussed in various places but nothing works for me. My question is: Does anyone know of a RECENT posting that provides a workable solution to getting an RSA filter to work with DataSnap/Indy/Firemonkey on an Android device? My current understanding that the root cause of the problem is probably the failure of Indy to remain current with Google's erratic development habits, that has deprecated OpenSSL in favor of a branch called Boring. Has this been addressed effectively by anyone? If not, are there any plans to do so? Thanks in advance, Milan

Hi) I need to statically link an existing Delphi app that uses Indy for networking with OpenSSL 1.0.2u. From the Indy code itself and some online resources I can see that Indy is capable of somehow statically linking with OpenSSL. But given Delphi can't link .lib files I try to figure out how do I build OpenSSL in a single object file so I can link it to the project. By now I've managed to compile it into a single obj by #including all the relevant source files into a single file. I made it compile by ifdefing certain structs in the code, got rid of macro redefinition warnings, solved the case insensitive linking issues and finally linked it to the project. But now I keep getting very weird errors, like e.g. call to CRYPTO_free yields access violation error and such. So obviously what I'm doing is more of a hack and it's probably wrong. I know that there has to be a way of doing it properly, could someone please direct me to the way it's supposed to be done. System: Windows 10 x64, RAD Studio Tokyo 10.2, I compile OpenSSL with MSVC for x64

Two new zips for Win32 and Win64 versions of OpenSSL 1.1.1i can now be downloadable from the Wiki at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp . The latest 1.1.1 DLLs are also included in the ICS distribution SVN and overnight zip. There are two security fixes, one rated high relating to decryption using SM2 (which standard ICS does not offer) and rated moderate relating to ASN.1 strings used in X509 certificates and the confusing conversion between fixed length strings and C null terminated strings that may cause a crash, this was mainly a problem display certificate content. YuOpenSSL has a new version with OpenSSL 1.1.1l. Angus

Hi there, I had some time to check out the great OpenSsl library from Grijjy / @Allen@Grijjy, and I found that its working even without binding any libraries to it. The original FMX sample showed some issues, so I just created a brand new Rx10.4.1 project and moved the main unit to it. Beside the Grijjy Foundation, I've put no static linked files yet in the deployment, to check this library out step-by step. Of coarse for Win32 I need the enclosed DLL's in the EXE folder, that's no surprise. It puzzled me that for Android and iOS, as well as for Macos, I don't need to add any library at all to the library tree/deployment Even in Allens post, there is the note, I've misinterpreted that it should be added directly to the projects library tree, or by deployment manager or some other hacky means: Also Embarcadero has notes about OpenSsl, Which leads to the conclusion at least iOS would need some external download of static libraries. In the libraries const section, I can spot the different static/dynamic names, but where and do they bind to ? const {$IF Defined(WIN32)} LIB_CRYPTO = 'libcrypto-1_1.dll'; LIB_SSL = 'libssl-1_1.dll'; _PU = ''; {$ELSEIF Defined(WIN64)} LIB_CRYPTO = 'libcrypto-1_1-x64.dll'; LIB_SSL = 'libssl-1_1-x64.dll'; _PU = ''; {$ELSEIF Defined(ANDROID64)} LIB_CRYPTO = 'libcrypto-android64.a'; LIB_SSL = 'libssl-android64.a'; _PU = ''; {$ELSEIF Defined(ANDROID32)} LIB_CRYPTO = 'libcrypto-android32.a'; LIB_SSL = 'libssl-android32.a'; _PU = ''; {$ELSEIF Defined(IOS)} LIB_CRYPTO = 'libcrypto-ios.a'; LIB_SSL = 'libssl-ios.a'; _PU = ''; {$ELSEIF Defined(MACOS32)} LIB_CRYPTO = 'libssl-merged-osx32.dylib'; { We unify LibSsl and LibCrypto into a common shared library on macOS } LIB_SSL = 'libssl-merged-osx32.dylib'; _PU = '_'; {$ELSEIF Defined(MACOS64)} LIB_CRYPTO = 'libcrypto-osx64.a'; LIB_SSL = 'libssl-osx64.a'; _PU = ''; {$ELSEIF Defined(LINUX)} LIB_CRYPTO = 'libcrypto.so'; LIB_SSL = 'libssl.so'; _PU = ''; {$ELSE} {$MESSAGE Error 'Unsupported platform'} {$ENDIF} I've put my test code as a wrapper around the original code, basically just adding the new project files. It seems the magic happens, because the libraries were sitting all side-by-side to the calling unit. The OpenSSL_Api unit find these local files in the same folder, and is able to bind them correctly. I didn't know that this is possible, I thought they have to be in the same project folder, and at least cross-platform make another hazzle to bind depending on the OS. Good to know that its enough to provide library+unit together, that gives much more room to cleanup libraries. I've put my wrapper code enclosed for testing, while the originally library files from Grijjy should be placed in the Src folder. The missing files you can get from here. I hope Allen don't mind. T381_GrijjySsl.zip

note: We have seen these issues with multiple versions of the OpenSSL binaries, including the ones bundled with ICS 8.64. Please consider the following code snippet: var s := TSslContext.Create(nil); try s.SslCALines.Text := sslRootCACertsBundle(); try s.InitContext(); except on e: exception do ShowMessage(e.Message); end; finally s.Free(); end; This snippet works on most machines, but we have a few machines at client sites, where this code raises an exception: 'Error reading info file "Lines"'. (We haven't figured out yet why these specific machines have this issue). This exception is raised on OverbyteIcsWSocket.pas:14667 (ICS 8.64). InfoStack := PStack(f_PEM_X509_INFO_read_bio(InBIO, nil, nil, nil)); if not Assigned(InfoStack) then raise ESslContextException.CreateFmt('Error reading info file "%s"', [FileName]); Apparently the call to f_PEM_X509_INFO_read_bio() failed, but no information is give why, so we've added some calls to f_ERR_get_error() to see what is going wrong, and then it turns out the call to f_PEM_X509_INFO_read_bio() sets the error code 151580774 (get_header_and_data). To find out which of the hard coded certificates returned by sslRootCACertsBundle() were making this error happening, we've passed each of the certificates (sslRootCACerts001, sslRootCACerts002, etc) one by one to an TSSLContext to see which ones failed. This showed 2 interesting things: There is a 'typo' in sslRootCACerts009 and sslRootCACerts011: 'AGAT/3B+XxFNSRuzFVJ7yVTav52Vr2ua2J7p8eRDjeIRRDq/r72DQnNSi6q7pynP' + #13#10 + '9WQcCk3RvKqsnyrQ/39/2n3qse0wJcGE2jTSW3iDVuycNsMm4hH2Z0kdkquM++v/' + #13#10 + 'eu6FSqdQgPCnXEqULl8FmTxSQeDNtGPPAUO6nIPcj2A781q0tHuu2guQOHXvgR1m' + #13#10 + '0vdXcDazv/wor3ElhVsT/h5/WrQ8' + #13#10; sslRootCACerts010 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + and 'S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb' + #13#10 + 'QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl' + #13#10 + '0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB' + #13#10 + 'NVOFBkpdn627G190' + #13#10; sslRootCACerts012 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + (the END CERTIFICATE line is part of the wrong constant), which isn't a problem when you call sslRootCACertsBundle() since all constants are concatenated, but which shows up if you try to use these certificates separately. More interestingly, one these specific machines there seems to be an issue with sslRootCACerts033 and sslRootCACerts034. This is sslRootCACerts033: # X509 SSL Certificate # Subject Common Name: GlobalSign # Subject Organisation: GlobalSign # Subject Organisation Unit: GlobalSign Root CA - R2 # GlobalSign Root R2 SHA1 • RSA • 2048 # Issuer: Self Signed # Expires: 15/12/2021 -----BEGIN CERTIFICATE----- MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1 MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8 eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG 3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO 291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7 TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg== -----END CERTIFICATE----- When processing this certificate on these specific machines OpenSSL gives this error, unless: - I remove one of the • in the 5th line from the top. (As long as there is only 1 • in the file it's ok, as soon as I add a 2nd • anywhere in the header the error returns) - I add a CRLF at the bottom of the file The same thing applies to sslRootCACerts034. I realize that this is probably a bug in OpenSSL itself, but it might be wise to remove the •'s from the hard coded certificates to work around this issue. Curious if anyone can shed some light on the cause of this 🙂 Merijn