I'm trying to add DirName and serial number to the X509 Authority Key Identifier extension using the FreeIPA/IDM server (not openssl) so it will looks like
X509v3 Authority Key Identifier
keyid:11:1B:30:08:A2:F0:F9:6C:D5:8D:24:E3:31:EA:D3:A8:FC:BC:13:FD
DirName:/CN=.
serial:D4.....
I tried to add parameters to a certificate profile and then requested an SSL certificate using this profile I tried by adding only the serial number first
policyset.serverCertSet.9.constraint.class_id=noConstraintImpl
policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=authorityKeyIdentifierExtDefaultImpl
policyset.serverCertSet.9.default.name=Authority Key Identifier
Extension Default
policyset.serverCertSet.9.default.params.authorityKeyIdentifierCertificateSe
rialNumber=1000
and I replaced the bottom line with:
policyset.serverCertSet.9.default.params.authorityKeyIdentifierCertSerialNumber=1000
policyset.serverCertSet.9.default.params.authorityCertSerialNumber=1000
However the serial number doesn't show in the Authority Key Identifier extension
Related
I have created a realm and added new keystore(RS384) in the Providers section
When I tried authenticate using postman. I am getting below error in Keycloak console
PublicKey wasn't found in the storage. Requested kid: 'Y3RDLAudovJPEU3Z9BMJL3OyuzqsgAj4424CpxnJqkI' . Available kids: '[]'
Kid is available in the Keys section for the Realm. I am not sure what is causing that. Any help on this is so much appreciated
Edit
Client Authentication
Added JWKS keys from certs endpoint
In Postman made call to token endpoint with client_assertion which has signed JWT and got response back "Invalid client: Unable to load Public key "
I think you gave wrong a value(or format) of "Private RSA Key" and "X509 Certificate" file when you add the key-store at Keycloak UI.
it is possible to get the public Key for RS384 by Postman and UI.
I demoed with Keycloak 18.0.0 with "ssh-keygen" & "openssl" on Ubuntu.
Generate RS384 private key and public key and certification file
ssh-keygen -t rsa -b 4096 -E SHA384 -m PEM -P "" -f RS384.key
openssl req -new -x509 -key RS384.key -out RS384-cert.pem -days 360
it will create three files
RS384-cert.pem <- certification file
RS384.key <- private key
RS384.key.pub <- public key
Add Keystore with 1.'s files
New Keystore will be created
Can get Key by Postman
can compare public key between UI and openssl generated it.
you can check API call value and JWT creator web site
with KID and public key
https://russelldavies.github.io/jwk-creator/
The issue is I did not add "use":"sig" in the JWKS that is kid is not available
I have been given a public xml key in the following format:
<RSAKeyValue>
<Modulus>MODULUS_VALUE</Modulus>
<Exponent>EXPONENT_VALUE</Exponent>
</RSAKeyValue>
With this key I need to verify a signed message that I would receive.
I have created a keystore with keytool but I am unable to import this public key there.
Is it possible to add this public key to a blank new jks keystore that I would create?
So far I haven't been able to do exactly that. I would imply that I don't have the private key, I only have the public key in xml format.
I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.
I received a new keystore .jks file for ssl connection to replace an old, but working, .jks keystore file, but I got "unexpected handshake message: serve_hello" error. I was told to make sure the keystore contains a client cert, so I used keytool to export its cert to a pem file, then use openssl to check the purpose. The result shows
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
...
However when I applied the same process to check the old but working jks file I got the same result. Wonder if this is the right way to verify the certificate? And how to troubleshooting this handshake error with the new jks file?
Thanks!
The extended key usage extension contains OIDs which define the purpose:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
https://datatracker.ietf.org/doc/html/rfc5280 Page 44
See: https://oidref.com/1.3.6.1.5.5.7.3.1 and https://oidref.com/1.3.6.1.5.5.7.3.2
When opening a certificate on Windows you can see the extension here:
I have a program that create self-sign certificate of RSA algorithm.
The problem is that if I create certificate of RSAES OAEP parameters,
when I open the certificate I see that the size of the public key is 0 bits .
Do anyone know what is the problem?
I already checked that the ASN 1.0 Encoding of the RSA OAEP Pararmeters is ok.
And if I create certificate RSA without OAEP Parameters than the size of the public key is present ok (not as 0 bits).
I checked in the internet and I didn’t find any certificate of RSA with OAEP pararms for example to compare with my certificate.
I will be glad for any suggestion.
This is the certificate in PEM File:
-----BEGIN CERTIFICATE-----
MIIFyzCCA7OgAwIBAgIDMaTyMA0GCSqGSIb3DQEBBAUAMG0xETAPBgNVBAMTCFN0YW0gSXNo
MRQwEgYDVQQHEwtQZXRhaCBUaWt2YTEPMA0GA1UECBMGSXNyYWVsMQwwCgYDVQQKEwNBUlgx
FjAUBgNVBAsTDVByaXZhdGVTZXJ2ZXIxCzAJBgNVBAYTAklMMB4XDTAwMDEwMTEwMDAwMFoX
DTk5MTAxMzIxNTYxNVowbTERMA8GA1UEAxMIU3RhbSBJc2gxFDASBgNVBAcTC1BldGFoIFRp
a3ZhMQ8wDQYDVQQIEwZJc3JhZWwxDDAKBgNVBAoTA0FSWDEWMBQGA1UECxMNUHJpdmF0ZVNl
cnZlcjELMAkGA1UEBhMCSUwwggJnMFIGCSqGSIb3DQEBBzBFoA8wDQYJYIZIAWUDBAIBBQCh
HDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiFDASBgkqhkiG9w0BAQkEBVRDUEEAA4IC
DwAwggIKAoICAQCizEvm86uS4/f8e7EC81OqNK+fIoCWOYJdc7iDNEbI+7l9C/zD//KiETMD
x1V4WgBXvhokc05a0oLdJ8MlcTFUGsmrX8mxesGnY87wVeJBJ+jPQipZ+ZoA16U9d4xOQU8b
erXUf+w6VFwoL4M3jLyL2lspHiMJPagsukxjzh1Dj/xA6tIVsSnJkffDyRC9l267pP1mXi2u
vAT4zhSX1FLtoO3XkJ0pJarIyJeTnBLMQ5ga1gnDmUFve4tI/cLbb9fxeTF7zA+XNrTTdYrY
9zkiMXBvnT7h0ZpGhfvobC7ULbmO/XyR3tVmuMoTu9mwNgjwCgp5f5Jt7cZbUJNbBateglcv
+Gb9FjFjneCRU4adN87GpyAMfclq5MIO+KCoRWSDRbL/6exYMf0sE3g4ARSru/7Wm82xITNA
fRn2qDErR421SiiuwkIlh97eiyfYeEb+n5eSOr1Qscr+tXOpEuArBDPzg0g5fo0dgomAVZvK
hwfOS+URUmobRPuUN5ecB4dALBJkkN02qaGkCXZmzWicnheXmhTYe3og0fQpajFXUwgwguXl
CDfy91Tn9PBYdRs0G0/gkiRABTP3sZvG3ru9I20W9tdfvN3NssBb+2AadRhSvpgP1wkHIVmZ
/VOQN893TdmaS+WQOiocxh2LxJv7QeC8j8fi9k8LTeM4JCqJ0wIDAQABoy8wLTArBgNVHRAE
JDAigA8xOTk4MDEwMTA4MDAwMFqBDzIwMDAwMTAxMDgwMDAyWjANBgkqhkiG9w0BAQQFAAOC
AgEAODPOHhl4J519jEExA2TIwSWLC23lloBQQPJysE0gelbyTv3xGVmJJZF+JAGvxrkvYado
UMPc9pBF57RsB7tznhCHpcYpSRcEIEArZoxfiVkevheLsm9/gyd5RA/oD6xx8WZBFFjHW+fs
urdJPEfR0lBHGmOKBKTa9aeqwJ5Bfi6Rm6/OvbalWBgZh2+5KYhdtMZH7JnsCCR6ZrJzLp8D
uo5M0iIQ/J6D9pDsPBmYK3/P/c7mVhLhjUBtqelkRGO690VzoBykf9MsWE3IT58gq1Av3dGe
J1LSgijha65s/A+l7zEC0fL7UFSXUnNCghEz+PkpcO14wFeg9UIypM0R85IOO0PBg4FVLACT
hmBmFFJCDOCgMwO+xMQZE+eG5gOEUgESHaQfEUoU7JxPHYB/9Xxl2G69nHr2Fx0KuLrjnrym
SgrFubQ3d+XuSTLxr/Lr7gl7EZP68uEsPcw2CXXdpsq4pvmVbrNspfHGn9SimFkEA8qmPqkt
4wiUPCwLkvY+qZ55JnmtPWoeaekJDx7iox0TtiHlQH6Y+/Rl18zU0lITePKPbc5thPZjiwIl
rR5O1PYzlIzE9m/7mFNitIAR2CixJRNiykgz5Q2gjYu4itmb2aHE1UuzK2mORny2gYnG7mdr
dD2y8hDouRCuxND/kkfdDyspGSRQcnqnmpkt7nQ=
-----END CERTIFICATE-----
Public key is 4096 bits long in the attached certificate. Using MD5 hash with 4k keys is very strange combination as MD5 hash is too weak and all strength of 4k key is eliminated by weakness of a hash.