![]() ![]() ftpd/ d/printer/ match ftp mError loading /etc/ssl/certs/ftpd.pem: p/Linux. The key and certificates are from a trusted party. Check Point FireWall-1 Secure FTP server running on/s p/Check Point. Openssl pkey -in keyfile.key -pubout -outform pemĤ684559980:error:09FFF064:PEM routines:CRYPTO_internal:bad base64 decode:/BuildRoot/Library/Caches//Sources/libressl/libressl-22.260.1/libressl-2.6/crypto/pem/pem_lib.c:800: openssl x509 -in clientCert.crt -textĤ559283820:error:09FFF06C:PEM routines:CRYPTO_internal:no start line:/BuildRoot/Library/Caches//Sources/libressl/libressl-22.260.1/libressl-2.6/crypto/pem/pem_lib.c:683:Expecting: TRUSTED CERTIFICATE XXXXXXXXXXXXXXXXXXXXXXXXhZSZgxxxxxxx4gv/5blW3Dc=īefore creating the PEM file, when I try validating the cert and key using openssl I get below error. XXXXXXXXXXXMVTXXXXXXXXXXXXBKueuqI6lfYygoKOhJJoXXXXXXXXXXXXXXXXXX Trying to create the PEM file in below format. the peer certificate first as it is detailed in an RFC and this order has been in the code base for longer than SChannel.I am having a server CA certificate, client certificate and client key files. I expected that the order of the certificates would be the same when changing the backend. If curl no longer makes this guarantee, then perhaps it is best to remove the odd code that is PR #4518 and just let Windows return it, in whatever order.Īccording to PR #4518, this is what was "expected" of curl - to return certificate order the same regardless of backend (OpenSSL/SChannel/BoringSSL/etc): If the purpose of that PR was to guarantee a particular ordering of the certificates returned by Windows from curl then it fails. This issue is primarily related to PR #4518 which no longer works on newer versions of Windows 11. When it finds whatever certificate in the CERT_CONTEXT certificate store that contains the extension then it returns that value. For your PR #10056, it is likely that CertGetNameString enumerates all the certificates in the chain looking for the subject alternative name extension (at least that is what it looks like from ReactOS code). You can use CertEnumCertificatesInStore to enumerate all the certificates in a CERT_CONTEXT. I think that the "end certificate/server certificate" (according to the MS docs) actually is a chain of certificates or "certificate context". It's supposed to contain the "end certificate" and we already rely on that elsewhere as the server certificate. However, it might be better to go with I have in my PR. Or it might also be possible to detect the order using CertGetIssuerCertificateFromStore in curl's certificate traversal function to see if the first certificate is the issuer certificate. It may be possible to build the chain using CertGetCertificateChain, however that might be an expensive operation. And subject to issuer ordering is what TLS guarantees itself. Instead, prior to Windows 11 22H2 they are in order from issuer to subject and after 22H2, they are in order from subject (leaf) to issuer (root). It sounds like Microsoft's position is that the certificates returned can be in any particular random order, however in practice we have not found that they are random. However, curl in #4518 tries to confer a particular order. curl/libcurl versionĪccording to MicrosoftDocs/win32#1384, there is no guarantee that the certificate store returned by Microsoft will have the certificates in any relationship ordering, even though TLS may have its own ordering/relationship guarantees. I want to bring awareness about the issue and hopefully we can get a solution for CURLINFO_CERTINFO when using SChannel that works consistently in all versions of Windows. I have also filed the issue on Microsoft Feedback Hub to get clarification, but I am not hopeful. So reversing the ordering of certificates in the chain in curl is no longer necessary according to how newer versions of Windows are behaving. ![]() In Windows 11 22H2 it appears that the incorrect ordering of certificates has been corrected and that subject certificates are now correctly appearing before issuer certificates. Note that the store also includes the end-entity (server) certificate, // so exclude this certificate from the set of |intermediates|.Ĭhromium now uses BoringSSL, but you can see there was a problem with the way that SChannel returned certificate chains. Reverse the list, so that intermediates are ordered from // subject to issuer. This is // likely because the default Windows memory store is implemented as a // linked-list. In testing, enumerating the store returned from SChannel appears to // enumerate certificates in reverse of the order they were added, meaning // that issuer certificates appear before the subject certificates. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |