I received five files representing a certificate for a specific domain.
AAACertificateServices.crt
TrustedSecureCertificateAuthority5.crt
USERTrustRSAAAACA.crt
private.key
public.crt
I want to import this certificate using AWS Certificate Manager, but it fails with the message that the private key does not match.
I found under https://stackoverflow.com/a/14491157 the method to convert the key to PEM format, but that's probably not enough. What to do with the chain and the public.crt?
Related
I have Java application running on two different servers. On the 1st server while the application is trying to insert a X.509 certificate to NSS keystore it is getting the following error:
Failed to store public key certificate in keystore. Cause: Could not create trust object
java.security.ProviderException: Could not create trust object
at sun.security.pkcs11.Secmod$TrustAttributes.<init>(Secmod.java:658)
at sun.security.pkcs11.Secmod$Module.setTrust(Secmod.java:529)
at sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1045)
at sun.security.pkcs11.P11KeyStore.engineSetCertificateEntry(P11KeyStore.java:516)
at java.security.KeyStore.setCertificateEntry(Unknown Source)
Using certutil to list the NSS DB entry I can see the certificate entry, but the trust flag says "CTu,Cu,Cu".
On the 2nd server, inserting a X.509 certificate to NSS keystore doesn't throw the same exception. It is working fine and using certutil I can see the certificate entry, and the trust flag says: "CT,C,C".
My questions:
Why on the 1st server inserting a X.509 certificate threw an exception?
What cause the trust flag to be different between the two certificate? The X.509 certificate is imported thru the same API.
Both servers are running Java 8u121. Thank you.
I saw there are two type of certificate which is elastic-stack-ca.p12 and elastic-certificates.p12. What are the differences between these two certificate.
https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html#generate-certificates
Also I noticed we have HTTP certificate
https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html#encrypt-http-communication
why there are so many certificate.
If I want to send data from beats which certificate should be used? I saw it need .cer and .key
can someone help me to understand this.
You need both, and each one has a specific role.
***ca.p12 is the certificate to the new Certificate Autohirity which is created since Elastic certificated is auto assigned.
***certificate.p12 is the certificate to each single instance of your elasticsearch cluster.
I would recommend you to follow the steps here https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html
Source:
https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html#certutil-ca
ca.p12 -> CA Mode
The ca mode generates a new certificate authority (CA). By default, it produces a single PKCS#12 output file, which holds the CA certificate and the private key for the CA. If you specify the --pem parameter, the command generates a zip file, which contains the certificate and private key in PEM format.
certificates.p12 -> Cert Mode
The cert mode generates X.509 certificates and private keys. By default, it produces a single certificate and key for use on a single instance.
To generate certificates and keys for multiple instances, specify the --multiple parameter, which prompts you for details about each instance. Alternatively, you can use the --in parameter to specify a YAML file that contains details about the instances.
I'm trying to use okhttp to authenticate to a server.
With curl it would be done this way:
curl \
--cert certificate.cer \
--key private-key.pkcs8 \
"https://some-url"
Unfortunately, okhttp-tls appears to always expect a chain of certificates in addition to the held certificate, which isn't something I have.
heldCertificate expects the chain of certificates, in addition to the clientCertificate, contrary to the example provided in the reame:
HandshakeCertificates clientCertificates = new HandshakeCertificates.Builder()
.addTrustedCertificate(rootCertificate.certificate())
.heldCertificate(clientCertificate) // <--------------------
.build();
How can I use okhttp with a single certificate and my private key?
heldCertificates expects a chain of intermediates that may exist between the client certificate (matching the private key) and up to but not including the root CA that the server is known to trust. So this could be left out if no other certificates are required.
See https://square.github.io/okhttp/4.x/okhttp-tls/okhttp3.tls/-handshake-certificates/-builder/held-certificate/
Configure the certificate chain to use when being authenticated. The
first certificate is the held certificate, further certificates are
included in the handshake so the peer can build a trusted path to a
trusted root certificate.
The chain should include all intermediate certificates but does not
need the root certificate that we expect to be known by the remote
peer. The peer already has that certificate so transmitting it is
unnecessary.
Here are some examples for using a self-signed certificate if known to be trusted already by the server, and also for switching the key used based on the host being connected to. You will need to adapt these based on your exact setup, but they should give you a starting point to test with.
https://github.com/square/okhttp/pull/6470/files
Keychain access - >certificate assistant -> request a certificate from a certificate authority -> save to disk -> save as .certSigningequest
Does not generate a public/private key chain, when I go to keys.
How do I solve this, thanks
Request a certificate from a certificate authority creates a Certificate Signing Request, not a public/private key chain. It will create the private key and store it in your key chain (as you named it), but the purpose of that command is to allow you to request a full X.509 certificate from an external Certificate Authority.
If you need to create just a public/private key pair, then it depends a bit on what you are planning on using it for. For example, you can create an SSH public/private key pair by using ssh-keygen.
Similarly, you can create an RSA public/private key pair using the commands from this answer from the security forum.
If, on the other hand, you're actually trying to create your own certificates, not just the public/private key pair, you can use Keychain Access to create a self-signed certificate using the Create a Certificate command. That will contain the signature of your self-signed CA and the public key.
I've acquired a signed certificate for use in a secure connection in Tomcat 7(.0.42). Here is what I'm given:
An x.509 certificate, primary-intermediate and secondary-intermediate x.509 certificates, an PKCS#7 chained certificate, and a private key.
I imported the certificates as specified in this guide using the x.509 certificates, then configured my SSL Connector to use the keystore, but got this error:
java.io.IOException: Alias name the_alias does not identify a key entry
I was advised to use the (also) provided PKCS#7 chained certificate, but when attempting to import it using keytool, it failed saying that it wasn't an x.509 certificate.
I understand from online lit that in the first step I was missing the "1" alias for the private key, but I have no idea how to import it. Also, I understand the PKCS#7 certificate is supposed to work fine on Tomcat, but I don't know how to import it to a keystore. I'm rather new to this, please advise!
Many thanks,
Victor.
I can not check how you implement the guide, but I do recommend to start from the self-signed certificate according to instruction here:
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
Ensure that keyAlias points to the alias of the server certificate in keystoreFile.
The default alias for the self signed certificate is tomcat.
<Connector port="8443"
…
keyAlias="tomcat"
…
keystoreFile="server.keystore" keystorePass="changeit"
truststoreFile="trust.keystore" truststorePass="changeit"/>
When it will work, replace the keyAlias with the alias of the signed certificate.