Are there some commonly used or standardized URI schemes or patterns that are used to identify SSL certificates, for example for description in linked data applications? The URI does not necessarily have to be resolvable, but it should be unique for a given certificate (and not something arbitrary).
For example, the fingerprint of the certificate used by stackoverflow.com is F4:AB:EB:33:1E:28:CC:EB:20:DA:7F:C1:8C:A9:55:90:C0:ED:1F:4E:63:F5:2B:63:7B:23:B9:BC:06:66:5E:64. A hypothetical example could be therefore something like urn:cert:thumbprint:F4ABEB331E28CCEB20DA7FC18CA95590C0ED1F4E63F52B637B23B9BC06665E64.
I have managed to find RFC 7512 that describes the pkcs11: scheme which has the serial attribute, but as far as I know, the serial does not have to be unique, only when coupled with the identifier of the certificate authority, but I don't think you can specify that in pkcs11:. I wasn't able to find anything else.
It is my own case for establishing TLS to get URI (I'm using SafeNet eToken) issuing command:
p11tool --list-all-certs 'pkcs11:model=eToken'
The result looks like this (sensitive data is masked):
Object 0:
URL: pkcs11:model=eToken;manufacturer=SafeNet%2C%20Inc.;serial=01234567;token=AlexXXXXXXXXXXXXXXXX;id=%00%11%22%33%44%55%66%77;object=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;type=cert
Type: X.509 Certificate (RSA-2021)
Expires: Xxx Apr 01 01:23:45 2021
Label: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ID: 00:11:22:33:44:55:66:77
The URL
URL: pkcs11:model=eToken;manufacturer=SafeNet%2C%20Inc.;serial=01234567;token=AlexXXXXXXXXXXXXXXXX;id=%00%11%22%33%44%55%66%77;object=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;type=cert
is contains serial number of token itself serial=01234567 and id of object on token id=%00%11%22%33%44%55%66%77. Unique couple.
UPDATE
In your case serial is not the serial number of a certificate, it's a serial number of token on which object (certificate) is located. You are mismatching the terms.
Related
I am trying to generate X509 certificates in C# code (using the class X509Certificate2) and upload these certificates to an Azure Key Vault. When I try to upload them (programmatically or via the Azure Portal in a browser), I get the following error message:
The specified X.509 certificate content is invalid. Error: one or more x.509 properties are invalid.
How can I debug what is wrong with my certificate generation? Is it documented what combinations of X509 properties are acceptable? If so, where can I read about it?
Output from certutil -dump foo.pfx:
> certutil -dump E:\Raven\Certificates\test2.pfx
Enter PFX password:
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
Serial Number: 86ae932f199f419115e8087f3f0cb6df747bd2adf966d46aab194f4283849635
Issuer: CN=intermediate CA
NotBefore: 24-01-2022 11:22
NotAfter: 25-01-2022 11:22
Subject: O=foo, CN=bar
Non-root Certificate
Cert Hash(sha1): a700464f1708cec627eabcd007ef574d1f0fc140
---------------- End Nesting Level 1 ----------------
Provider = Microsoft Software Key Storage Provider
Private key is NOT plain text exportable
Signature test passed
CertUtil: -dump command completed successfully.
In my case it turned out to be two things:
The serial number. I was using RandomNumberGenerator.GetBytes(32) to generate serial numbers, which was apparently bad. The vault is happier if I do Guid.NewGuid().ToByteArray().
The flags (enum X509KeyUsageFlags). I tested several combinations of flags, and it turns out that whenever I use the flag X509KeyUsageFlags.KeyEncipherment the vault will reject the certificate.
I don't know why. I suppse that if you use the KeyEncipherment flag, there is some other invariant that the certificate needs to obey.
In any case, when I fix the serial numbers and remove this flag, it appears that the vault accepts my certificates.
If I fix only the serial number but keep the KeyEncipherment flag, I get this error message:
Unsupported key operation(s): "wrapKey", "unwrapKey". Supported values are "sign", "verify".
I'm sorry in advance if something bring you here and I talk about a platform that's not really well-known over the world despite featuring a well-known person dancing in their commercial.
It's Shopee Open Platform API I talk about. I was trying to follow very properly their instruction here.
https://open.shopee.com/documents?module=63&type=2&id=51
But stuck instantly at step 5 : Shop Authorization. First, I've been given a test partner id, a test key, and I need to set manually the test redirect URL. I have to generate authorization token from all given information. Firstly I need to create a token base string by concatenating the test key with URI component encoded string of the URL. It turns into something like this.
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
To generate the authorization token, it says I need to do hexencode(sha256(token_base_string)). It returned a very long integer.
32373935663639356636346266303137613465396239383361373334646133656530313333393762636138396364663037366566313366313436316534303761
So I just assumed everything is fine and that is the authorization token. But when I send this...
https://partner.uat.shopeemobile.com/api/v1/shop/auth_partner?id=(test_partner_id)&token=(authorization_token)&redirect=(test_redirect_URL)
... suddenly I get this
{
"error": "error_auth",
"msg": "Invalid token",
"request_id": "30a4b6b0074541bdd88260a33f155ca6"
}
In order to solve this, you have to understand that SHA256 is an Encryption hash function. Please research more on SHA256 on your specific language.
For this very specific case, your SHA256 token should be as below.
Before SHA256:
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
After SHA256:
2795f695f64bf017a4e9b983a734da3ee013397bca89cdf076ef13f1461e407a
The rest of your steps seems correct.
Can PEM_read_X509 function read in a CA cert file with private key properly? is it intelligent enough to handle the private key section? Or it will error out if the .pem file contains the private key?
TLDR: YES
Almost all OpenSSL PEM_read[_bio]_XYZ functions will accept a file (or equivalent) containing other data before and/or after the PEM block of type XYZ, and ignore the other data as long as it's not on the same line(s). This is designed to allow 'comments' that describe the PEM data, but also works for other types of PEM data or just arbitrary data not related to the PEM data at all. In particular PEM_read_X509 will read the first block of type CERTIFICATE, X509 CERTIFICATE, or TRUSTED CERTIFICATE and ignore anything and everything else, including a private key block.
Similarly PEM_read_[algo_or_PKCS8]PrivateKey will read the first block of type [ENCRYPTED|RSA|DSA|EC] PRIVATE KEY and ignore everything else, but fail if you tried to read a specific algorithm and the (first) private key block found was a different type. (It also fails, of course, if a valid block is found but is encrypted by a password and you don't provide the correct password either as an argument or via a callback. And if no valid block is found.)
I'm not sure if by 'CA cert' you mean a cert for a CA, or a cert issued by a CA and for an end-entity like your webserver or mailbox. Except for a personal/local or test CA you or a colleague or your organization set up, most ordinary users should have the certs for one or more CAs but never their privatekeys. And if someone responsible for a real CA like say LetsEncrypt was asking such basic questions on Stackoverflow I would be greatly alarmed and worried over the competence and thus security of that CA.
According to here:
A digital certificate contains:
Serial Number: Used to uniquely identify the certificate.
Subject: The person, or entity identified.
Signature Algorithm: The algorithm used to create the signature.
Signature: The actual signature to verify that it came from the
issuer.
Issuer: The entity that verified the information and issued the
certificate.
Valid-From: The date the certificate is first valid from.
Valid-To: The expiration date.
Key-Usage: Purpose of the public key (e.g. encipherment, signature,
certificate signing...).
Public Key: The public key.
Thumbprint Algorithm: The algorithm used to hash the public key
certificate.
Thumbprint (also known as fingerprint): The hash itself, used as an
abbreviated form of the public key certificate.
My question is, how does the signature come from? I think it is used to ensure the digital certificate is issued by a trusted issuer. So the issuer use its private key to sign on something to produce the signature, then the verifier of the certificate must have the corresponding public key of the issuer to decipher the signature and verify that this something is genuine.
If I am correct, this something must be stored in the certificate as well for the verifier to compare the deciphered signature to. So what's this something? Could it be the thumbprint (hash) of the public key?
This something is most of the certificate itself. The receiver can calculate the hash over the TBSCertificate (the part of the certificate To Be Signed) itself using the algorithm in the certificate. The receiver can then verify that it is the same as the hash calculated by the signer (the issuer of the certificate). If the signature is verified and the signer is trusted, then the certificate is verified.
There are more tests to be performed such as validating that the certificate has not been revoked or over it's date of expiry before it can be fully trusted.
A digital certificate consists of:
certificate information
signature algorithm
signature value
See the RFC 5280 for more info on the exact structure of the certificate.
I used sample code from DotNetOpenAuth.net to become my own OpenID Provider (OpenIDProviderWebForm) everything worked fine and I was able to test my OP against NerdDinner. now I want to customize the identifier like --->
http://www.mydomain.com/user.aspx/Hash(Username+PrivateKey)~Username.
everything works on OP side but on the NerdDinner application when the app tries to do
HttpRequestInfo clientResponseInfo = new HttpRequestInfo("GET", auth, auth.PathAndQuery, headers, null);
response = RelyingParty.GetResponse(clientResponseInfo);
(you can find these two lines of codes in AuthController.cs from NerdDinner)
the response contains below error:
The OpenID Provider issued an assertion for an Identifier whose discovery information did not match.
Assertion endpoint info:
ClaimedIdentifier: http://localhost:57571/user.aspx/76208371132EC7F7A37472C8B4CC2CC37A05B707~sohail
ProviderLocalIdentifier: http://localhost:57571/user.aspx/76208371132EC7F7A37472C8B4CC2CC37A05B707~sohail
ProviderEndpoint: http://localhost:57571/server.aspx
OpenID version: 2.0
Service Type URIs:
Discovered endpoint info: [
{
ClaimedIdentifier: http://localhost:57571/user.aspx/EA467E35736AC22EB60C04C2E9D9594263B60ECB~sohail
ProviderLocalIdentifier: http://localhost:57571/user.aspx/EA467E35736AC22EB60C04C2E9D9594263B60ECB~sohail
ProviderEndpoint: http://localhost:57571/server.aspx
OpenID version: 2.0
Service Type URIs:
http://specs.openid.net/auth/2.0/signon
http://openid.net/extensions/sreg/1.1
}, {
ClaimedIdentifier: http://localhost:57571/user.aspx/EA467E35736AC22EB60C04C2E9D9594263B60ECB~sohail
ProviderLocalIdentifier: http://localhost:57571/user.aspx/EA467E35736AC22EB60C04C2E9D9594263B60ECB~sohail
ProviderEndpoint: http://localhost:57571/server.aspx
OpenID version: 1.0
Service Type URIs:
http://openid.net/signon/1.0
http://openid.net/extensions/sreg/1.1
},
]
anybody can help me please?
The relying party is reporting that the Provider is asserting information about an identifier that doesn't match what the OpenID discovery produces about that same identifier.
Your responsibility as a Provider includes making sure your assertion matches the identifier information. So consider what is under the "Discovered endpoint info" in the error message, and why it's different than what was asserted (above it). In this case, your ClaimedIdentifier and ProviderLocalIdentifier URLs are different between the asserted and discovered data. This may be because an HTTP GET on the asserted identifier actually generates an HTTP redirect to the URL under "discovered endpoint info", which you'd need to fix.