I have created a Self-Signed Certificate in Mac OS using Keychain Access to be used as a certificate for my AIR Application. After exporting a release build for my app in Flash Builder 4.6, I have verified my apk using jarsigner by executing the following command:
jarsigner -verify -verbose -certs myapp.apk
then, the following message was returned:
jar verified.
Warning:
This jar contains entries whose signer certificate is not yet valid.
is it ok to publish this app on Google Play?
if possible, how to validate my self-signed certificate?
root cause for my problem: since Google Play requires a certificate to be expired after October 22, 2033, i have changed my system date to an advance date.
Valid value for the validity period of Keychain Access certificate assistant is 20 years so if I'll create a new certificate, it will expire on June 26, 2033 which fails to achieve the requirement.
A validity period for an X509 certificate is the number of days the certificate
is valid from the time it is issued. Certificates issued by Certificate Assistant
have a maximum validity period of 20 years.
upon using this certificate for the code signing of my air application, Google Play prompts an error upon uploading the apk
Upload failed
You uploaded an APK signed with a certificate that is not yet valid.
You need to sign your APK with a certificate that is currently valid.
Learn more about signing.
So i created a new certificate using keytool by executing the following commands:
$ keytool -keystore cert.jks -genkeypair -alias cert -keyalg RSA -keysize 2048 \
-validity 18250 -dname 'CN=cert,OU=org,O=org,L=location,ST=state,C=PH'
$ keytool -keystore cert.jks -exportcert -alias cert \
| openssl x509 -inform der -text
$ keytool -importkeystore -srckeystore cert.jks -destkeystore cert.p12 \
-srcstoretype jks -deststoretype pkcs12
Related
I am developing a REST server that runs with Jersey on Glassfish, and I want to make it run on HTTPS on localhost.
I have found many tutorials for generating a CA cert, others for generating .cer / .crt / .key / .csr / ... files, others for generating a jks keystore.
But they do not answer my (very basic) question: how to generate a self signed certificate and use it in my app that runs on Glassfish, on localhost? From scratch to the integration for a real usage, without any prerequiresite having a crt, a jks or any other file.
(For information I use Linux)
Thanks
EDIT: I have finally created a certificate with the following commands
openssl req -x509 -out localhost.crt -keyout localhost.key \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
openssl pkcs12 -export -name localhostServerCert -in localhost.crt -inkey localhost.key -out localhostP12Keystore.p12
keytool -importkeystore -destkeystore localhostKeystore.jks -srckeystore localhostP12Keystore.p12 -srcstoretype pkcs12 -alias localhostServerCert
copy localhostKeystore.jks into /glassfish/domains/domain1/config
keytool -importkeystore -srckeystore localhostKeystore.jks -destkeystore keystore.jks
And I have modified http-listener-2 in the admin console with certificate nickname localhostServerCert, but I got an error page on https://localhost:8181 (ERR_CONNECTION_REFUSED)
EDIT 2 : I think there should be a problem with the certificate, since openssl s_client -showcerts -connect localhost:8181 returns no peer certificate available, No client certificate CA names sent
COMMON GOALS
It can be useful to run with SSL locally, and I like to start with real world URLs. This can also help you to think ahead to your production deployment design, which often involves a Private PKI these days, based on a self issued Root CA.
Web and API domains can sometimes be related these days, eg if an API issues secure cookies for the web origin. So for localhost development I first define URLs such as these:
https://api.mycompany.com
https://web.mycompany.com
DEVELOPER SETUP
Then add entries such as this to my hosts file:
127.0.0.1 localhost web.mycompany.com api.mycompany.com
:1 localhost
Then, in terms of certificates, I produce these deployable files:
Certificate
Filename
Usage
Root CA
mycompany.ca.pem
The root certificate authority that is trusted by the Java runtime
Wildcard Certificate
mycompany.ssl.p12
A password protected PKCS12 file deployed with the API
My Development Certificates Repository has an example of how to issue the certs using openssl, including a bash script you can use for your own domains. Essentially this is a Private PKI for a development computer.
CONFIGURING TRUST
You then just need to trust the Root CA in the Java runtime used by Glassfish. Personally I tend to avoid JKS files where possible, since they are specific to Java, whereas PKCS12 files are a more portable concept:
sudo "$JAVA_HOME/bin/keytool" -import -alias mycompanyroot -cacerts -file ~/Desktop/mycompany.ca.pem -storepass changeit -noprompt
FURTHER DEVELOPER SETUP INFO
These resources on a portable way to manage SSL development certs are provided below, which completes the architecture work:
My Developer SSL Blog Post
My Java API uses the above certs and loads the wildcard certificate via this code, where a P12 file is used as a keystore:
System.setProperty(
"server.ssl.key-store",
configuration.getApi().getSslCertificateFileName());
System.setProperty(
"server.ssl.key-store-password",
configuration.getApi().getSslCertificatePassword());
GLASSFISH
If Glassfish based setups mean the API itself does not load the PKCS12 file, then there may be a specific task to import the PKCS12 file. Many systems provide a GUI or API option for loading a PKCS12 file into a keystore. This may result in a command like this being run, which you can do manually if needed:
keytool -importkeystore -srckeystore mycompany.ssl.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -deststoretype jks -v
I am trying to setup 2 way ssl authentication. My requirement is broker should authenticate only specific clients.
My organization has a CA which issue all certificates in pkcs12 format. steps i followed are as follows.
get a certificate for the broker and configured it in the broker keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
ssl.client.auth=required
get a certificate for the client and configured it in the client keystore
ssl.keystore.location=/home/kafka/certificate.p12
ssl.keystore.password=xxxxx
extracted the public certificate from the client certificate using keytool command
keytool -export -file cert -keystore certificate.p12 -alias "12345" -storetype pkcs12 -storepass xxxxx
imported the certificate into broker truststore. broker truststore contains only the client 12345 certificate.
keytool -keystore truststore.p12 -import -file cert -alias 12345 -storetype pkcs12 -storepass xxxxx -noprompt
configured the truststore in the broker.
ssl.truststore.location=/home/kafka/truststore.p12
ssl.truststore.password=xxxxx
configured the truststore in client. client truststore contains CA certificates.
ssl.truststore.location=/etc/pki/java/cacerts
ssl.truststore.password=xxxxx
When i run the broker and client i expect the broker to authenticate the client and establish ssl connection. but instead following error is thrown.
[2021-06-03 23:32:06,864] ERROR [AdminClient clientId=adminclient-1] Connection to node -1 (abc.com/10.129.140.212:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2021-06-03 23:32:06,866] WARN [AdminClient clientId=adminclient-1] Metadata update failed due to authentication error (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLProtocolException: Unexpected handshake message: server_hello
I tried various things but nothing seems to work. when i replace the broker truststore with /etc/pki/java/cacerts truststore file which contains only the CA certificate
then it works fine. but it will authenticate any client which has certificate issued by the CA.
what could be the issue ?
The default format is jks,
use keytool to create a Java KeyStore (JKS) with the certificate and key for use by Kafka. You'll be prompted to create a new password for the resulting file as well as enter the password for the PKCS12 file from the previous step. Hang onto the new JKS password for use in configuration below.
$ keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12 -alias myserver.internal.net
Note: It's safe to ignore the following warning from keytool.
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore server.p12 -destkeystore kafka.server.keystore.jks -srcstoretype pkcs12"
I have installed Nexus Repository Manager OSS 3.0.2-02 on my CentOS Linux release 7.4.1708.
Also I have CA certificate:
Issued to: \*.mycompany.com
Issued by: Go Daddy Secure Certificate Authority - G2
Valid from 2016-11-12 to 2018-01-11
The RSA private key match with my CA certificate, which was checked with Certificate Key Matcher and reported:
The certificate and private key match!
In Nexus3 directory I made the following changes:
Added to the file org.sonatype.nexus.cfg the lines:
nexus-args=${karaf.etc}/jetty.xml,${karaf.etc}/jetty-http.xml,${karaf.etc}/jetty-requestlog.xml,${karaf.etc}/jetty-https.xml
application-port-ssl=8443
Added to jetty-https.xml file next lines:
KeyStorePath /ssl/test.jks
KeyStorePassword 123456
KeyManagerPassword 123456
TrustStorePath ssl/test.jks
TrustStorePassword 123456
Created SSL directory in $NEXUS_HOME/etc/ and created inside the SSL directory a Java keystore file test.jks with command:
openssl pkcs12 -export -in mycompany.com.pem -inkey key.pem -name xxx.mycompany.com -out test.pks
keytool -importkeystore -deststorepass 123456 -destkeystore test.jks -srckeystore test.pks -srcstoretype PKCS12
keytool -import -alias bundle -trustcacerts -file gd_bundle.crt -keystore test.jks
After Nexus restart I can't not reach it by URL //xxx.mycompany.com:8443. Firefox says:
The page you are trying to view cannot be shown because the
authenticity of the received data could not be verified
Also trying to do: docker login xxx.mycompany.com:8443 and providing default admin:admin:123 credentials cause:
Error response from daemon: Get xxx.mycompany.com:8443/v1/users/:
x509: certificate signed by unknown authority
I also try to chain certificates by various scenarions from Google, including How to add certificate chain to keystore?, but got error on Docker:
Error response from daemon: Get //xxx.mycompany.com:8443/v1/users/: EOF
on Firefox, the same as first time and on Chrome:
//xxx.mycompany.com unexpectedly closed the connection
Question: Where is my mistake, or how to correctly install CA certificate on Nexus3?
I've found the resolution. Just needed to set in jetty-https.xml next lines:
<Set name="NeedClientAuth"><Property name="jetty.ssl.needClientAuth" default="false"/></Set>
<Set name="WantClientAuth"><Property name="jetty.ssl.wantClientAuth" default="false"/></Set>
I just got an Thawte 123 SSL Certificate and have problems uploading it to AWS to use it with CloudFront as Custom SNI SSL Certificate. AWS refuses the CA Chain. I'm using the Thawte Intermediate CA bundle for SSL Web Server and Thawte Wildcard certificates.
To be able to use my private key I converted it to an RSA key with:
openssl rsa -in private.key -out private-rsa-key.pem`
And tried to upload it with:
aws iam upload-server-certificate --server-certificate-name example.com-certificate --certificate-body file://certificate.pem --private-key file://private.pem --certificate-chain https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL_CA_Bundle.pem --path /cloudfront/example.com/
Resulting in the following error:
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Even Inserting the thawte_Primary_Root_CA.pem into the certificate chain as first immediate signing certificate, doesn't resolve the problem.
A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 1
Is the Thawte CA Chain not compatible to AWS?
I am having the same issue right now, and tried everything.
Using SSL123 certificate (My rsa key and pem are ok)
I can't get to work the primary and secondary certs provided by Thawte, in any order.
I tried primary alone, secondary alone, primary+secondary, secondary+primary, also tried with the root cert and also tried with the primary&secondary from:
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_SecondaryCA.pem
https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL123_PrimaryCA.pem
The only thing I can get from ELB is:
Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 0
Where the index is not always -1, but also 0,1 and 2 depending on the order and the number of certs included.
[SOLVED FOR ME]
Apparently, the EC2 instance from which you create the certificate affects. I used a standard EBS instance with default AMI, and transformed the certificate provided by Thwate again, and it did work.
Here the steps:
CSR:
keytool -genkey -keysize 2048 -keyalg RSA -alias mycertificate -keystore keystore.jks
Once Thatwe responds: (Primary is the second certificate in the chain of the email).
Import the three certificates in the keystore.jks
keytool -import -alias Primary -trustcacerts -file Primary.crt -keystore keystore.jks
keytool -import -alias Secondary -trustcacerts -file Secondary.crt -keystore keystore.jks
keytool -import -alias mycertificate -trustcacerts -file mycertificate.cer -keystore keystore.jks
JSK > P12 - Transform keystore.jks into p12 format
keytool -importkeystore -srckeystore keystore.jsk -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12
P12 > PEM - Transform p12 format into pem format
openssl pkcs12 -in keystore.p12 -out keystore.pem -nodes
PEM > RSA PRIVATE KEY - Export the private key in RSA format
openssl rsa -in keystore.pem -text > keystore_rsa.pem
And it did work this time.
you must make sure that the certificate, private key, and certificate chain are all PEM-encoded as following:
-----BEGIN CERTIFICATE----- << -This is my Intermediate CA which signed my CSR
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- << -This is my Root CA which signed my Intermediate CA
Base64-encoded certificate
-----END CERTIFICATE-----
You don't need to put your signed certificate in the chain.
Just add the intermediate and root ca in the Chain files should be enough.
Using the folliowing as ca chain certificate solves the problem:
https://ssltools.thawte.com/chainTester/webservice/validatecerts/certificate?certKey=issuer.intermediate.cert.57&fileName=thawte%20DV%20SSL%20CA%20-%20G2&fileExtension=txt
It is important to note that the intermediate certificates are not specific to your domain or certificate. So, every certificate issued that is like yours, has the exact same intermediate certificates.
You can think of them a bit like the routing number on your checks. The routing number is needed, but really says more about your bank than it does about you. Your account number, or your certificate in this case, is what is unique to you.
Because of the generic nature of the intermediate certificates there are websites like this one:
https://www.ssl2buy.com/wiki/ssl-intermediate-and-root-ca-bundle
That have all of the intermediate certificates pre-bundled (and in the correct order) for different certificate issuers.
I'm trying to enable SSL for Boomi webservices. I've followed the instructions on their documentation to generate the CSR and sent it to CA for signing. I've received the signed certificate in .pem format. I've looked at the contents of the file and it doesn't contain any information about any private key.
These are the steps on Boomi's documentation.
1) Replace the keystore path, KEYSTORENAME and –dname parameters in this command with your information (this –dname “….” option can be omitted if the trusted root authority requests this information when submitting the CSR) and run the following command to generate the key:
keytool -genkey -dname "CN=HOSTNAME, OU=ORGUNIT, O=ORG, L=LOCATION, S=STATE, C=COUNTRY" -alias Boomi -keyalg RSA -keystore c:\Certificates\Boomi\KEYSTORENAME -keysize 2048
2) Replace the KEYSTORENAME in this command and run the following command to generate the CSR:
keytool -certreq -keyalg RSA -alias Boomi -file c:\Certificates\Boomi\KEYSTORENAME.csr -keystore c:\Certificates\Boomi\KEYSTORENAME
3) Submit the CSR to the Trusted Root Authority (for example, Verisign), and request/download the returned certificate in PKCS7 format. This will have a public, G3 intermediate, and G5 intermediate certificate all in one certificate. Java must be 1.6 or newer.
4) Replace the certificate file path\name and keystore path\name in this command and run the following command to import the PKCS7 certificate:
keytool -import -alias Boomi -trustcacerts -file c:\Certificates\Boomi\NEWCERTNAME.p7b -keystore c:\Certificates\Boomi\KEYSTORENAME
5) Replace the new and destination keystore paths/names and passwords (if different from changeit) in this command and run the following command to convert to .p12 format for import into Boomi:
keytool -importkeystore -srckeystore c:\Certificates\Boomi\KEYSTORE -destkeystore c:\Certificates\Boomi\KEYSTORENAME.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass changeit -deststorepass changeit -srcalias Boomi -destalias Boomi -srckeypass changeit -destkeypass changeit -noprompt
I'm stuck at step 4 because I don't have the signed certificate in .p7b format. I've searched around for any information about how to convert .pem file to .p7b file, and all of them mention that the .pem file will contain key information along with the certificate information. But since the .pem file that I have doesn't have the key info, how should I go about converting .pem to .p7b and eventually arrive at .p12 cert.
Also, if possible, can you please explain what do these formats mean?
First, check out this ServerFault answer for information on keys and keyformats.
Second, to address your issue, the .pem file may or may not contain private key information. In the case of a signed certificate (signed after submitting CSR to the CA), it typically will not inlcude the private key. In your instructions, the private key exists in the keystore, already. I believe the command in instruction number 4 will import the trustchain (.p7b) into the keystore, so you'll have the public key, private key, and trust chain all in the same [protected] file.
If you don't have the file in the .p7b format, you could request the CA send it to you in .p7b format.
Barring that, the first thing I would try is changing the command to include the .pem file instead of the .p7b file. keytool is pretty smart, and I would think it would figure out what it needed to do to import the .pem instead of the .p7b.
If that doesn't work for some reason, there's more you can do, but things start to get more complicated. I would start with this link. Good luck!