I have a leaf certificate installed on my machine, which was issued by a Certificate Authority (CA); this CA is not present on the system.
If I am given the thumbprint (i.e. the SHA-1 hash) of the CA, can I look up and thereby retrieve the installed leaf signers issued by this CA? If I am able to, then what are the required Windows function calls for accomplishing this?
I have been examining a leaf certificate and I only see the standard string representation name of the CA and not a thumbprint. This string name is not unique, hence why I am utilizing the thumbprint (SHA-1’s poor security here is not a problem as it is only used for looking up a proper signer). Microsoft has the CertGetIssuerCertificateFromStore function, but this requires having the CA in memory.
No, it is not possible to look up an issued leaf signer using only the issuer's CA's thumbprint. You first have to install the CA on the machine and then use the entirety of the CA to find its issued leaf signers. The CA's thumbprint is not stored in the leaf signers it issues from what it appears.
All in all, the first operation that needs to be done is installing the CA on the machine you want to find its issued leaf signers on.
Related
A little new to windows programming/C++. I'm trying to install a .p7b root certificate file to the Trusted Root Certificate Store. I want to use the Windows Wincrypt library. Specifically, these are the suggested steps that I got from an old forum:
Call CertCreateCertificateContext using your certificate content bytes
in order to obtain a PCCERT_CONTEXT
Call CertOpenSystemStore with szSubsystemProtocol set to "ROOT" in
order to obtain a HCERTSTORE
Call CertAddCertificateContextToStore using the above HCERTSTORE and
PCCERT_CONTEXT.
[Here's] the api documentation for CertCreateCertificateContext. Not sure how to just point pbCertEncoded to my actual cert file. Should I just point it to the path? Do I have to load the cert in? What should the type be?
From Simon Rozman's answer in this post: We have to use CertOpenStore() instead of
CertCreateCertificateContext(), which supports one certificate only, whereas PKCS #7 file can contain many.
After the certificate store is open, you can use CertEnumCertificatesInStore() to retrieve certificate context of individual certificates from store.
So from my original steps to successfully install a p7b into the root store:
Call CertOpenStore() for the root store and for the actual certificate itself. This will give you two HCERTSTORE handles.
Have a while loop that will add the certificate contexts to the opened root store (using CertAddCertificateContextToStore()) as long as the certificate context exists (check using CertEnumCertificatesInStore() on the opened certificate store).
I am working with self-signed certificates and certificate manager of Windows OS.
First of all, I have created a self-signed certificate "RootCA" which has a private/public key pair assigned, nevertheless I have destroyed private key of this certificate with the next certutil.exe command succesfully:
certutil -user -delkey "RootCA"
Also, I have check refreshing and exporting private key and it is not possible, because it has been destroyed.
The problem is when I visualize "RootCA" in Certificate Manager after destroying private key, "General" tab indicates that "You have a private key that corresponds to this certificate.":
My question is:
Are there any way to update/remove previous certificate information? And if yes, is it possible to do it programmatically?
With Microsoft CryptoAPI setting pvData parameter of CertSetCertificateContextProperty function to NULL solves the problem.
I am using libcurl and shifting cert pinning to AWS root as per this document https://www.amazontrust.com/repository/
I used the SHA-256 Hash of Subject Public Key Information data from that website, formed a string:
static string PUBLIC_KEY = "sha256//fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2;sha256//7f4296fc5b6a4e3b35d3c369623e364ab1af381d8fa7121533c9d6c633ea2461;sha256//36abc32656acfc645c61b71613c4bf21c787f5cabbee48348d58597803d7abc9;sha256//f7ecded5c66047d28ed6466b543c40e0743abe81d109254dcf845d4c2c7853c5;sha256//2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92";
and set the string to curl
curl_easy_setopt(handle, CURLOPT_PINNEDPUBLICKEY, PUBLIC_KEY.c_str());
The curl error I get is CURLE_SSL_PINNEDPUBKEYNOTMATCH
Google does not have any insight into why, as far as I searched. If anyone has any input on how to fix this and still pin to the root, it would be super useful. Thanks.
Found the reason. Root pinning is not supported yet.
13.11 Support intermediate & root pinning for PINNEDPUBLICKEY
CURLOPT_PINNEDPUBLICKEY does not consider the hashes of intermediate & root certificates when comparing the pinned keys. Therefore it is not compatible with "HTTP Public Key Pinning" as there also intermediate and root certificates can be pinned. This is very useful as it prevents webadmins from "locking themself out of their servers".
Adding this feature would make curls pinning 100% compatible to HPKP and allow more flexible pinning.
https://curl.haxx.se/docs/todo.html
We want to replicate our on-site MySQL database to AWS. Needless to say we need a secure connection, and setting that up has proven to be surprisingly difficult. The AWS Data Migration Service looked like the right thing, and it has the option to import a certificate.
After trial and error I discovered that AWS needed the .pem extension to even try to upload the file. According to the documentation, it expects a chained certificate file, which I have. But I get a validation error every time, with absolutely no helpful details as to what is wrong. I ensured that my private key is only 2048 bits long, as AWS seems to have trouble with larger ones. I have run the certificate through various online tools and they say it is OK. It seems that the first part of the certificate is the problem, Data Migration is happy to import the second part all by itself. Also worth noting, AWS Certificate Manager was willing to take the entire thing (though there it forces you to split the file). The certificate was generated by Let's Encrypt/Zero SSL with my CSR. I have confirmed there are no extra whitespaces in uploading the file.
-----BEGIN CERTIFICATE-----
MIIFBTCCA+2gAwIBAgISA9w/KQIPfQ7G1qbtWy6eruVwMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzEwMTUxMjU2MzZaFw0x
ODAxMTMxMjU2MzZaMBwxGjAYBgNVBAMTEWVxLnNlbnRyeWxpbmsuY29tMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4GXdQB1u967ZpUuSpaBpzVWFsIXk
YYvDVbX+1DoygaIhqAAoL+s8RgZf8jz49tbFlBc06eXhDH9qL47ZcdLUahY3TY0G
Aksl1uUpxivt7Am3WvzoeTuCO8vhObVNpVLLcyKQ7H543jswLehhSgcPKiSF3ffw
qHJMst4bw4bmzHeTp6ZX83xek8YbXE48PUktpE4sGxwHbQVTuWLDCmMJZr/Pwz6i
fpbkxoUhv4jzlwsAtyPmRIa/XTYhGhnRuPD5m1ZX2LkAuKCH4crYuXPp+F+lMc1R
K0DGoQYk0QjP2nuLmqmJPByHRaTBMb+UwvJn1Ady7qyyS+3nIzG87fzvmwIDAQAB
o4ICETCCAg0wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQFXP07WkX+3XSghpNPYr0W
3Q6LBjAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcB
AQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlw
dC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw
dC5vcmcvMBwGA1UdEQQVMBOCEWVxLnNlbnRyeWxpbmsuY29tMIH+BgNVHSAEgfYw
gfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEFBQcCARYaaHR0
cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGeDIGbVGhpcyBD
ZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBSZWx5aW5nIFBh
cnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZpY2F0
ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVwb3Np
dG9yeS8wDQYJKoZIhvcNAQELBQADggEBAFxM5i3VlCpyrK0/Dnw5vtkV5TG+o/fJ
TG8elTQD8NDEuuZUee0u0jdcvP3CSGkRJo7tF1lBih8ns7Dhu2wxouM9r+3nP+7F
CYRF1BRAzj6gsTPpHX1XOv98Nq+s8NXQNFe+WxPlYtUQ4ZoJ+gVcNpm8zQY1GaMA
vb6osuru0WoOA3YeNiuRUSvMFnUMt0hO9DuknUdbbr/i9OphOz6xiWCLFPUtNNos
79yoanGZs9Kt40Ou4yhW1gZLHJfp461r0bzoh848f3+R2fwVaBUGBEYLxPNBCu7U
CK0Iualw5hRhh6620f79Lv2Z2FNrPq5kMIySaLpDWgaj5pQjXAjAVXM=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
UPDATE: The answer, which was to focus on the intermediate certificate, is correct. Using just the intermediate was enough to get a data load completed. However, to get data load with continuing replication, you will indeed have to add in the root certificate from your certificate authority as well. Convert it to PEM format and add that to the end of the intermediate bundle, and give the resulting file to AWS.
Data Migration is happy to import the second part all by itself.
The second part is what DMS needs, not the first.
To assign a certificate to an endpoint, you provide the root certificate or the chain of intermediate CA certificates leading up to the root (as a certificate bundle), that was used to sign the server SSL certificate that is deployed on your endpoint.
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.SSL.html#CHAP_Security.SSL.Limitations
DMS wants to be able to validate the cert on your endpoint, so it only wants the cert of the authority that signed it -- and apparently not the actual endpoint cert itself.
The "validation failed" is probably related to the fact that your first cert is your endpoint cert, which is not a CA cert.
If you check your certs with openssl x509 you note that the first file isn't a CA file...
X509v3 Basic Constraints: critical
CA:FALSE
...but the second one is.
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
I suspect that is all you need.
However, what you have here is an intermediate. If you want to build the full chain, then you need to append the root. According to Let's Encrypt, their Intermediate CA that signed your cert was in turned signed by IdenTrust DST Root CA X3.
This checks -- confirmed out by comparing the Authority Key Identifier of Let's Encrypt Authority X3 to the Subject Key Identifier of DST Root CA X3 (again, using openssl x509).
So, remove your first cert, and upload only the second.
If this isn't sufficient, add the body of the IdentTrust DST Root CA X3 certificate to the end of your file. It's at the URL linked above, and also pasted below:
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----
I'm looking at Boost's SSL Client. There's a reference to OpenSSL in the comments (sorry, no line numbers):
// The verify callback can be used to check whether the certificate that is
// being presented is valid for the peer. For example, RFC 2818 describes
// the steps involved in doing this for HTTPS. Consult the OpenSSL
// documentation for more details. Note that the callback is called once
// for each certificate in the certificate chain, starting from the root
// certificate authority.
Proper OpenSSL use and verification can be tricky. From experience, I know I have to perform the following to use the library correctly:
Disable SSLv2, SSLv3, and Compression on the Context object
Provide the proper root certificate for chain building and checking
Call SSL_get_peer_certificate and verify the certificate is non-NULL
Call SSL_get_verify_result and verify the result is X509_V_OK
Perform name matching (CN or SAN must match requested host)
OpenSSL 1.1.0 will provide name checking, but its only in HEAD at this point in time. From the OpenSSL Change Log:
Integrate hostname, email address and IP address checking with certificate
verification. New verify options supporting checking in opensl utility.
And:
New functions to check a hostname email or IP address against a
certificate. Add options x509 utility to print results of checks against
a certificate.
I don't see where Boost is performing any of the configurations or checks in the client code.
What precisely is Boost configuring, and what is it checking or verifying in its asio library component when using SSL?
Short answer: The Boost callback function, from the link you cited, doesn't verify anything. It returns whatever preliminary verification result was supplied to it by OpenSSL (via bool preverified). If there is any fine grained verification required (like the CN match, etc.), it has to be done explicitly by the callback.
Long answer: By the time the OpenSSL (or the Boost wrapper for OpenSSL) calls the verification function, in this case, bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx), a set of preliminary (or mandatory) verification is already done by OpenSSL. This is explained in the documentation.
The certificate chain is checked starting with the deepest nesting level (the root CA certificate) and worked upward to the peer's certificate. At each level signatures and issuer attributes are checked. Whenever a verification error is found, the error number is stored in x509_ctx and verify_callback is called with preverify_ok=0. By applying X509_CTX_store_* functions verify_callback can locate the certificate in question and perform additional steps (see EXAMPLES). If no error is found for a certificate, verify_callback is called with preverify_ok=1 before advancing to the next level.
The documentation also cites an example of how a more fine-grained verification callback could be written. You can draw inspiration from that depending on what your needs are.
EDIT: To be sure that Boost's internal callback function doesn't do anything special other than calling the application callback function, I took a look at engine.ipp, the C++ module that invokes OpenSSL's SSL_set_verify to set up callback functions. Take a look at how verify_callback_function is implemented. It simply invokes the application callback.