why PDF Reader doesn’t show the embedded OCSP Response?
I haven't even used crlClient:
MakeSignature.signDetached(sap, new BouncyCastleDigest(), es, chain, null, ocspClient, tsClient, 0, MakeSignature.CryptoStandard.CMS);
// chain[0] - signer certificate
// chain[1] - OperCA certificate (signer's issuer)
// chain[2] - RootCA (OperCA's issuer)
PDF revocation tab details shows:
The selected certificate is considered valid because it does not
appear in the Certificate Revocation List (CRL) that is contained in
the local cache.
The CRL was signed by "B-Trust Operational CA QES <[hidden email]>" on 2014/02/19 07:53:35 +02'00' and is valid until 2014/03/21 07:53:35 +02'00'.
I want to achieve the Figure 3.8 A digital signature with an embedded OCSP response, from Bruno Lowagie's free White Paper document.
What do I do wrong or miss?
Here is the Certification path and sample pdf.
Best Regards, Valentino
The actual issue is that even when PDF has embedded only OCSP response,
Acrobat Reader doesn't show it, but shows local CRL instead.
This is caused of non-conforming, to RFC6960 or RFC2560, OCSP certificate.
Wrong OCSP certificate path:
Root CA -> Operational CA -> Client certificates (certificates checked with OCSP)
Root CA -> OCSP
Right OCSP certification path:
Root CA -> Operational CA -> Client certificates (certificates checked with OCSP)
Operational CA -> OCSP
Related
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'm trying to secure a REST API using TLS/SSL, to do so I needed to update my client to use the public key and certificate.
The client is written in dart and here's how I implemented the SecurityContext :
SecurityContext clientContext = SecurityContext.defaultContext;
var certificate = (await rootBundle.load("assets/ssl/coastr.crt")).buffer.asInt8List();
print(certificate.toString());
clientContext.setTrustedCertificatesBytes(certificate);
/*var authorities = (await rootBundle.load('assets/ssl/coastr.ca-bundle')).buffer.asUint8List();
print(authorities.toString());
clientContext.setClientAuthoritiesBytes(authorities);*/
var key = (await rootBundle.load("assets/ssl/coastr_public.key")).buffer.asInt8List();
print(key.toString());
clientContext.usePrivateKeyBytes(key);
HttpClient client = HttpClient(context: clientContext);
HttpClientRequest request = await client.getUrl(Uri.parse(url));
HttpClientResponse response = await request.close();
The certificate (.crt file) is added without issue to the clientContext but adding the key to it returns me this error :
[ERROR:flutter/lib/ui/ui_dart_state.cc(148)] Unhandled Exception:
TlsException: Failure in usePrivateKeyBytes (OS Error:
BAD_PKCS12_DATA(pkcs8_x509.c:606)
passed a null parameter(ssl_privkey.cc:375), errno = 0)
The files I'm using are :
coastr.crt with this as a header : -----BEGIN CERTIFICATE-----
coastr_public.key with header : -----BEGIN PUBLIC KEY-----
I have no idea if I'm providing the wrong files to the client or if the error comes from elsewhere.
The files where generated using openssl.
Thank you for your help.
In general, you shouldn't have to add anything to the client to allow it to connect to a correctly configured HTTPS server. Hopefully, the server has a signed server side certificate. If that certificate is signed by a reputable CA, the client should automatically trust it. If it is signed by an in house CA, or self signed, you need to do some work. You need to provide the client with the signing certificate. In the former case that would be the root CA's certificate. In the latter case, supplying the server's certificate may work, though it's probably easier to disable the client check altogether.
The signing certificate is likely to be in CRT form as you've found. And you need to supply that exactly as you are doing. There's no need to supply any public keys as the are distributed in the certificates sent with the server hello.
Unless you want to use a client side certificate, there's no need to supply a private key, so you can skip the step that is failing. And supplying a public key to it is definitely not going to work, anyway.
I am trying to obtain the CRL from an OpenXPKI server (the default configuration is used). Requesting and polling of a certificate is possible.
On the OpenXPKI server, I revoked some certificate, created the CRL and published the list. To obtain the CRL I tried different approaches.
First approach:
X509CRL crl = client.getRevocationList(jscepCertificate, jscepKeyPair.getPrivate(),
certificate.getIssuerX500Principal(), certificate.getSerialNumber());
Second approach:
X509CRL crl = client.getRevocationList(jscepCertificate, jscepKeyPair.getPrivate(),
crlIssuer, crlSerialNumber);
On the server my CRL has the following information:
CRL Serial: 511
CRL Issuer: CN=CA ONE,OU=Test CA,DC=OpenXPKI,DC=ORG
Items: 25
When I try the above code examples (and also some other) I get following error on the CRL requester:
org.jscep.transaction.OperationFailureException: Operation failed due
to badCertId
And on the OpenXPKI server I get the following error:
openxpki.application.ERROR:12156 [OpenXPKI::Service::SCEP::Command::PKIOperation
(/usr/lib/x86_64-linux-gnu/perl5/5.20/OpenXPKI/Service/SCEP/Command/PKIOperation.pm:255);
scep-server-1()#f68c] SCEP getcrl - no issuer found for serial 511 and
issuer DC=ORG,DC=OpenXPKI,OU=Test CA,CN=CA ONE
Always no issuer found for serial XXX and issuer YYY (XXX and YYY depend on the send information of the CRL request).
Please, could anyone help me or give me some advice? - Thanks in advance!
I solved the problem with the help of the JSCEP and OpenXPKI communities. The problem is that the DN of the issuer is reversed, this means e.g. CN=CA,OU=Test CA,DC=OpenXPKI,DC=ORG is changed to DC=ORG,DC=OpenXPKI,OU=Test CA,CN=CA ONE and the getCRL from the OpenXPKI has no entry for the reversed issuer.
An easy fix is to reverse the issuer for the getCRL request (check OpenXPKI fix) by changing the code from the get_getcrl_issuer_serial.pm file. Add the following code in line 107:
$issuer = join ",", reverse split (/,/, $issuer);
A solution for the future would be to make the getCRL logic requester independent and to order the issuer on the request.
I am testing a sandbox version of the PayPal IPN system that worked previously, but is now not functioning. The IPN simulator says:
"IPN was not sent, and the handshake was not verified. Please review your information."
I reviewed the documentation about the Verisign G5 CA certificate and followed the instructions shown, but the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /etc/ssl/certs/
Still produces this output: (Truncated)
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 9E01CD86FA9E600EAD505F17E34C0F9BE07E7894E35B20BAF2946F88596BB047
Session-ID-ctx:
Master-Key: 90F662CD0BD319EB87ACFE89CDACEFED2327AC4C827ED74861166B86423B5404
587A70B65BCEA2FAC23F7DDAAA49F9DC
Key-Arg : None
Start Time: 1445624886
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
I verified that the G3 certificate is no longer in the certificate store, and even removed and reinstalled the new certificate many times. I have spent the last 10 hours on this with no end in sight.
I own my own servers, so there is no other administrator I can turn to... I need to figure out how to solve this myself, and am at my wits end. I know I do not know as much about SSL and certificate chains as I should, but theres no help for that part lol.
Can anyone who has performed this task give me a kick in the right direction, and/or let me know what additional information I can provide to help solicit a solution?
Thank you very much,
Dave
Here's how I did to import the G5 root cert into openssl:
Obtain a G5 root certificate from Verisign (Symantec) HERE (get it in PEM format, save the file with .pem extension)
Put the file into your openssl base dir (should be like "/usr/lib/ssl" on your server, but you may check the base dir by running openssl version -d)
Run the command to install the cert
openssl verify -CApath <ssl-base-dir>certs server-certificate-file
(replace <ssl-base-dir> with your openssl base dir, and replace server-certificate-file with your .pem file, the command would be something like openssl verify -CApath /usr/lib/ssl/certs G5.pem)
The response would be an G5.pem: OK for the installation
Try again with the connection command
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /usr/lib/ssl/certs/
You will see Verify return code: 0 (ok) at the end of the response
I downloaded the VeriSign Class 3 Public Primary Certification Authority - G5.pem certificate file into a local directory, and ran the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts
-CAfile "ssl\VeriSign Class 3 Public Primary Certification Authority - G5.pem"
Openssl returned a successful result (truncated):
Server certificate
subject=/C=US/ST=California/L=San Jose/O=PayPal, Inc./OU=PayPal Production/CN=api-3t.sandbox.paypal.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 3379 bytes and written 344 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 9E01CD86FA9CEB77AD505F17E34C0B9B8A233BD98E30D705F2946F88596F077D
Session-ID-ctx:
Master-Key: 7AC616B7499ED70B6D75FAD3308C332A48B85987685A514365B7507297A3C6A70CD6E7503CE27A9A157045531B54149F
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1445867355
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Note that I used the -CAfile option to directly reference the CA root certificate.