How to create a VeriSign certificate store with OpenSSL?

Question

OpenSSL

Good afternoon.

There are three files: the certificate request, the private key, and the certificate itself signed by VeriSign. I need to add this to the Java Key Store in order to use it in a Tomcat application. The problem is that the request was issued using OpenSSL and keytool doesn't seem to know how to import keys. Therefore, I decided to first export the certificate to the PKCS12 format store using OpenSSL, and then import this store into the Java Key Store. But here's the problem - when I try to export the certificate to the store with the creation of a chain (chain) using the command
openssl pkcs12 -export -in certificate.cer -inkey key.pem -out keystore.p12 -chain -CAfile ca.pem
(the ca.pem file contains both intermediate VeriSign certificates, as well as all VeriSign root servers pem files that I found in the roots.zip archive on their site)
I get an error message:
Error unable to get local issuer certificate getting chain.
I also tried adding intermediate certificates to the /etc/ssl/certs/ directory with the creation of the correct symlinks (symlink filename = certificate hash + .0), the error did not disappear.
Tell me, what certificate and where should I add in order for the command to be executed?

PS Certificate Issuer value:
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at www.verisign.com/rpa ©10, CN=VeriSign Class 3 International Server CA - G3

Answer 1

Sorry, I didn't insert the Issuer value:
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at www.verisign.com/rpa ©10, CN=VeriSign Class 3 International Server CA-G3

Answer 2

Everything is simple. In PKCS12, you do not need to insert a certificate chain. This can be done at the JKS generation stage.
Create PKCS12:
openssl pkcs12 -export -in webserver.cer -inkey webserver.pem -out webserver.p12
Create a JKS certificate store and import our data there
# keytool -v -importkeystore -srckeystore webserver.p12 -srcstoretype PKCS12 -destkeystore tomcat.jks -deststoretype JKS
Copy the certificate of an external CA (let's call it CA_cert.cer)
# scp<источник>:CA_cert.cer .
Install it in both local stores Assign access rights to Everyone.
# keytool -import -alias cacert-file CA_cert.cer -keystore tomcat.jks
# keytool -import -trustcacerts -file CA_cert.cer -keystore truststore.jks -storepass <пароль для JKS> -alias externalca
# chmod +x *.jks

Answer 3

It looks like this is due to the lack of the Authority Key Identifier extension. keytool simply cannot associate the end certificate with the issuing CA. There are several types of issuer mapping in Windows CryptoAPI: via Authority Key Identifier, via Issuer's DN, and so on. Therefore, in Windows, such a certificate may work, but there is no guarantee. Here is what the RFC 5280 standard says about the Authority Key Identifier:
The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction. There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted. The
signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key. (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.
Your certificate contains the following extensions: Missing X509v3 Authority Key Identifier: keyid:D7:9B:7C:D8:22:A0:15:F7:DD:AD:5F:CE:29:9B:58:C3:BC: 46:00:B5 These are my thoughts.
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
Full Name:
URI:http://SVRIntl-G3-crl.verisign.com/SVRIntlG3.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.3
CPS: www.verisign.com/rpa
X509v3 Extended Key Usage:
Netscape Server Gated Crypto, TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
CA Issuers - URI:http://SVRIntl-G3-aia.verisign.com/SVRIntlG3.cer
1.3.6.1.5.5.7.1.12:
0`.^.\0Z0X0V..image/gif0!0.0...+......Kk.(.....R8.).K..!..0&.$http://logo.verisign.com/vslogo1.gif

Answer 4

Do you need JKS? Or is the goal just to set up SSL under Apache? It's just that you don't have to use JKS for SSL.
In general, the problem lies in a somewhat different plane. Various methods are used to match the issuer and the final certificate: Exact match, Key match, Name match. The first two methods require the Authority Key Identifier extension. Means there is only Name match. It seems that keytool cannot build chains in Name match mode. Therefore, nothing depends on JKS, it is necessary to tweak the client using JKS in such a way that he can build the entire chain from beginning to end.