I'm using Sonatype Nexus 2.5.0-04. I'm trying to add a SSL certificates in the user interface, as described in the documentation here:
http://books.sonatype.com/nexus-book/reference/ssl-sect-client-cert.html
The documentation says "The administration interface for SSL certificates as visible in Figure 23.1, 'SSL Certificates Administration' and can be accessed by selecting SSL Certificates in the right hand Administration menu."
Where is the "right hand Administration menu"? I've looked everywhere. I can't find a link for SSL certificates in the GUI anywhere. I thought perhaps this might be a feature available only in the professional version, but there is no mention of that in the documentation on the differences between the two versions.
This is a feature that is only available in Nexus Professional and it should be the left hand navigation.. I will fix this in the book.
Update: Documentation is now fixed.
I would like to make an appreciation about configuring Nexus front with SSL and a self-signed certificate because when you use the keytool to generate de keystore.jks file as is indicated in https://support.sonatype.com/hc/en-us/articles/213465768-SSL-Certificate-Guide?_ga=2.171695904.1899216110.1638870535-818117565.1624006959
keytool -genkeypair -keystore keystore.jks -storepass password -alias example.com \
-keyalg RSA -keysize 2048 -validity 5000 -keypass password \
-dname 'CN=*.example.com, OU=Sonatype, O=Sonatype, L=Unspecified, ST=Unspecified, C=US' \
-ext SAN=DNS:nexus.example.com,DNS:clm.example.com,DNS:repo.example.com,DNS:www.example.com'
you obtain an Invalid keystore format error bacause the default TrustStoreType of keytool is PKCS12. I had to force it to JKS to be able to start Nexus with the -storeType option.
keytool -genkeypair -keystore keystore.jks -storeType JKS -storepass password -alias example.com \
-keyalg RSA -keysize 2048 -validity 5000 -keypass password \
-dname 'CN=*.example.com, OU=Sonatype, O=Sonatype, L=Unspecified, ST=Unspecified, C=US' \
-ext SAN=DNS:nexus.example.com,DNS:clm.example.com,DNS:repo.example.com,DNS:www.example.com'
I don't know if you could correct it in the documentation or at least to make some appreciation about.
I've found this problem with the Nexus' version 3.30.1.01.
Related
I'm tinkering with a self-signed certificate on RH Linux 7 for a tomcat instance, but having a hell of a time so that I don't have browser warnings. I've followed this guys instructions here (Getting Chrome to accept self-signed localhost certificate) and tried importing the .crt into my tomcat instance using keytool. Using the following commands -
Create the keystore - keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tomcat.keystore
Import the myCA.pem file created in the stackoverflow steps - keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file myCA.pem
And finally import the .crt created from the stackoverflow - keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file signed.crt
Now on the Linux 7 box I can access server.domain.com:8443 or server:8443 with a warning, but on my Windows workstation I can only access server:8443, not the FQDN. I've imported both the myCa.pem and signed.crt into my computer as trusted root authorities.
What am I doing wrong? Thanks much!
What I could understand is . You have generated SSL certs and imported in you machine.
Hope you have updated the conf/server.xml with ssl information . After updating restart the service and check
I am using keycloak-8.0.1 in standalone configuration . I am trying to enable SSL/Https for Keycloak server running on my Test machine (A.B.C.D) , token request will be requested from machine (X.Y.Z.P).
(Will there be any CORS/CSRF issue for the generated token , looks like yes ? And will Keycloak over SSL help to solve this?) Nevertheless i require SSL enabling .
So went ahead with https://www.keycloak.org/docs/latest/server_installation/#enabling-ssl-https-for-the-keycloak-server
Step 1 Run command :
keytool -genkey -alias localhost -keyalg RSA -keystore keycloak.jks -validity 10950
...
two files server.key and keycloak.jks got created.
Question : should i used localhost here or better to use IP A.B.C.D of my Test machine? Though documentation says localhost so went ahead with that.
Step 2 Generate a certificate request :
$ keytool -certreq -alias yourdomain -keystore keycloak.jks > keycloak.careq
I can also generate the cert request using localhost/A.B.C.D.
Step 3: Send the cert req created in above step to CA and download the root cert from CA(root.crt) and import using command:
keytool -import -keystore keycloak.jks -file root.crt -alias root
Do i have to skip this step for localhost and if not how to generate root.crt for localhost.
step 4: last step is to import CA generated certificate to keystore
$ keytool -import -alias yourdomain -keystore keycloak.jks -file your-certificate.cer
Question: Now i have only two files generated in very first step "server.key" and keycloak.jks
and from where i should get root.crt and your-certificate.cer ? I tried uploading the ca request to CAcert.org but they dont create certificate for localhost DNS.
I already went through lot of links link1 , link2 , link3 link4 and getting confused
Please help.
Answer 1-
If you are testing this in your local machine you can use localhost but better would be if you are using IP-address or host name
Answer 3
Again if its for your testing you can use Self Sign Certificate only,No need to go to Ads Certificate authority.
Answer 4-
So for localhost or your machine IP simple Create Certificate with the help of keytool
keytool -genkey -alias initcert -ext san=ip:xxx.xxx.xxx.xx -keyalg RSA -keystore keycloak.jks-validity 365 -keysize 2048
Export the certificates
keytool -export -noprompt -trustcacerts -keystore keycloak.jks -alias initcert -file keycloak.cer -storepass changeit
Import Certificates into Client machine Java Keystore
keytool -import -noprompt -trustcacerts -alias "initcert" -file keycloak.cer -keystore /workspace/tools/jdk/java-1.7.0-openjdk-1.7.0.25.x86_64/jre/lib/security/cacerts
I am trying to establish a secure connection for my application using jetty http server version 8.1.8.v20121106 with self signed certificate.
I am generating self signed certificate with the following command,
keytool -genkey -alias mykey -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 365 -keypass password -keystore keystore.jks -storepass password
keytool -export -alias mykey -file server.cer -keystore keystore.jks -storepass password
keytool -import -alias mykey -file server.cer -keystore truststore.jks -storepass password
So, totally 3 files generate (keystore.jks,server.cer,truststore.jks)
After the server gets started, I got the following error in my browser. There are issues with the site's certificate chain (net::ERR_CERT_AUTHORITY_INVALID).
Could anyone help me to generate a trusted self signed certificate using keytool.
Thanks in advance.
It is the problem with java jdk. I have verified using java 1.8 and jdk1.7.0_79 it is working fyn for me. Change your java jdk version and verify. For further clarification, Please refer this link.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398644
I'm using openssl to create self-signed certs. I'm getting this error with the certs I generated:
javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative names
present
Does anyone know how to specify "Subject alternative name" while creating a cert?
This is how I'm generating a keystore:
sudo $JAVA_HOME/bin/keytool -genkey -dname "CN=192.168.x.xxx, OU=I, O=I, L=T, ST=On, C=CA" -alias tomcat -validity 3650 -keyalg RSA -keystore /root/.keystore -keypass abcd -storepass abcd
To generate a key:
openssl s_client -connect 192.168.x.xxx:8443 2>/dev/null
Please help! Thanks!
Although this question was more specifically about IP addresses in Subject Alt. Names, the commands are similar (using DNS entries for a host name and IP entries for IP addresses).
To quote myself:
If you're using keytool, as of Java 7, keytool has an option to
include a Subject Alternative Name (see the table in the documentation
for -ext): you could use -ext san=dns:www.example.com or -ext
san=ip:10.0.0.1
Note that you only need Java 7's keytool to use this command. Once you've prepared your keystore, it should work with previous versions of Java.
(The rest of this answer also mentions how to do this with OpenSSL, but it doesn't seem to be what you're using.)
Both IP and DNS can be specified with the keytool additional argument -ext SAN=dns:abc.com,ip:1.1.1.1
Example:
keytool -genkeypair -keystore <keystore> -dname "CN=test, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass <keypwd> -storepass <storepass> -keyalg RSA -alias unknown -ext SAN=dns:test.abc.com,ip:1.1.1.1
When generating CSR is possible to specify -ext attribute again to have it inserted in the CSR
keytool -certreq -file test.csr -keystore test.jks -alias testAlias -ext SAN=dns:test.example.com
complete example here: How to create CSR with SANs using keytool
I am using self signed certificate for HTTPS connection to and from Axis2 server. All of these connections works fine and as desired.
There is a part in my web service which is responsible for sending emails. I am using GMail for the purpose of sending mail.
The problem is when I try to send a mail using an SSL connection I get certificate error, i.e. GMail certificate is not trusted. I had faced a similar problem with JBoss as well. For once I was able to get around this problem downloading GMail certificate and than importing it into the Keystore using Keytool utility. For a long time this had worked.
But only recently I have started to get the Old problem again. I tried to use the old technique that fixed the problem last time, but this time that did not work. (not sure why)
I reckon that GMail uses a signed certificate which out of the box should be trusted by any of the servers, let it be JBoss or Axis2. I fail to figure out what the problem actually is. Is it because of using of Self Signed certificate? Or are there any specific way of creating it so that the Signed certificates are trusted?
Thanks for the help.
To have a SSL encrypted Server/Client communication we need to Keystores and Truststore for Server & Client. Following are the steps to create them.
#Creating Server keystore and exporting a certificate
keytool -genkey -alias serverkeys -keyalg RSA -keystore server.keystore -storepass changeit -keypass changeit -dname "CN=test.com, OU=Test, O=Test, L=London, ST=London, C=UK"
keytool -export -alias serverkeys -keystore server.keystore -storepass changeit -file server.cer
#Creating Client keystore and exporting a certificate
keytool -genkey -alias clientkeys -keyalg RSA -keystore client.keystore -storepass changeit -keypass changeit -dname "CN=test.com, OU=test, O=test, L=London, ST=London, C=UK"
keytool -export -alias clientkeys -keystore client.keystore -storepass changeit-file client.cer
#Making a copy of cacerts file. These copies will be used for client/server truststore
cp /usr/java/jdk1.6.0_14/jre/lib/security/cacerts client.truststore
cp /usr/java/jdk1.6.0_14/jre/lib/security/cacerts server.truststore
#Copying server certificate to Client truststore
keytool -import -trustcacerts -v -keystore client.truststore -storepass changeit -file server.cer
#Copying Client certificate to Server truststore
keytool -import -trustcacerts -v -keystore server.truststore -storepass changeit -file client.cer
During the first few iteration I was not using cacert but directly create truststores from the certificate and that too worked well. Problems came up when we need to connect to some other services using SSL and connection could not be establised even when the service used a Signed Certificate.
For example connecting to GMail SMTP server would faile if the truststore were not created up from cacerts. Reason being even though GMail uses a signed certificate, we wold be using a truststore that would not know if the GMail certificate can be trusted. For this reason we used cacerts to create out truststore. After which we were able to connector any service that uses a Signed Certificate.
If in case we encounter a unsigned certificate we will then have to add them to the Components Truststore.