Using the following command:
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55.x86_64/bin/keytool -import -alias tomcat -trustcacerts -file certificate.crt -keystore $OBM_HOMEconf/keystore
I receive the error:
keytool error: java.security.cert.CertificateException: java.io.IOException: Illegal header: -----BEGIN CERTIFICATE-----
I generated the certificate on GoDaddy, as I had done previously for the server I'm trying to install this cert on, and downloaded the Tomcat version of the files from them.
I ensured all of the hyphens are actual hyphens (I've had an issue before where they came out as em dashes) in both the cert and the command. I do not understand why it is saying that the cert header is an illegal header.
Java's PEM parser is a bit finicky when it comes to extra whitespace. A trailing space character in the header line causes this error message.
Related
I am trying to invoke a secured endpoint (https) from wso2 integration studio8.0/MI 4.0. Created integration project, created an endpoint with the url with secured endpoint address, provided on header with the transport scope as required for the secured endpoint. I got the public key certificate (.p7b/.cer) and imported to the trust store using key tool utility.
keytool -import -alias aliasName -file public-key-from-browser.cer -keystore client-truststore.jks -storepass password. Provided the truststore file path in deployment.toml in integration studio/MI4.0 but getting the following exception. Please let me know how to resolve the exception.
[2022-01-17 10:28:09,696] ERROR {TargetHandler} - I/O error: General SSLEngine problem javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:270)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:316)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:541)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:591)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1729)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:333)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1015)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1012)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1504)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:288)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:356)
... 9 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:450)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:317)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:289)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1675)
Make sure that you have imported the chain of certificates. If you have already done that better to enable ssl debug logs [1] and analyse the ssl logs to identify what is the exact cause of the issue.
[1]-https://dilsichandrasena.medium.com/how-to-enable-ssl-debug-logs-for-wso2-products-6de7276ffe10
I setup Rundeck with LDAP/AD auth via JAAS module (vide official documentation).
Auth. works perfectly fine with non-encrypted connection (providerUrl="ldap://AD-FQDN").
When I am trying to switch from LDAP to LDAPS (providerUrl="ldaps://AD-FQDN"), that's where problem begins.
I gathered AD cert along with Sub and Root CA's, added them into rundeck truststore (and keystore afterwards) and restarted rundeckd.
Certs are being validated successfully:
[root#rundeck01 ssl]# openssl verify -CAfile RootCA.cer -untrusted SubCA.cer ad01.cer
ad01.cer: OK
What I can see in service.log:
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Firewall ports are opened (can connect to p. 389,636 from via telnet).
Running on:
rundeck-3.4.0.20210614-1
CentOS 7.9
Kindly advise.
Extract the ldaps server cert:
echo -n | openssl s_client -connect your_ldap_server:636 > cert.out
Import to the Rundeck's truststore:
keytool -importcert -trustcacerts -file cert.out -alias myldap -keystore etc/rundeck/truststore
Add the truststore path on your rundeckd file (-Djavax.net.ssl.trustStore):
RDECK_JVM_OPTS="-Drundeck.jaaslogin=true \
-Djava.security.auth.login.config=/etc/rundeck/jaas-ldap.conf \
-Dloginmodule.name=ldap \
-Djavax.net.ssl.trustStore=/etc/rundeck/truststore"
Same issue solved here.
I'm trying to build a Docker image, based on ubuntu:20.04, with R and bookdown with PDF support. But I'm getting ERROR: cannot verify yihui.org's certificate [...] with tinytex::install_tinytex():
> tinytex::install_tinytex()
trying URL 'https://yihui.org/tinytex/TinyTeX-1.tar.gz'
trying URL 'https://yihui.org/tinytex/TinyTeX-1.tar.gz'
--2020-11-23 09:19:05-- https://yihui.org/tinytex/TinyTeX-1.tar.gz
Resolving yihui.org (yihui.org)... 167.99.129.42, 134.209.226.211
Connecting to yihui.org (yihui.org)|167.99.129.42|:443... connected.
ERROR: cannot verify yihui.org's certificate, issued by 'CN=SSL-SG1-GROBU,OU=Operations,O=Cloud Services,C=US':
Unable to locally verify the issuer's authority.
To connect to yihui.org insecurely, use `--no-check-certificate'.
Error in download.file(url, output, ..., method = method) :
'wget' call had nonzero exit status
Calls: <Anonymous> ... download_file -> <Anonymous> -> download -> download.file
In addition: Warning messages:
1: In download.file(url, output, ..., method = method) :
URL 'https://yihui.org/tinytex/TinyTeX-1.tar.gz': status was 'SSL peer certificate or SSH remote key was not OK'
2: In download.file(url, output, ..., method = method) :
URL 'https://yihui.org/tinytex/TinyTeX-1.tar.gz': status was 'SSL peer certificate or SSH remote key was not OK'
You may have to restart your system after installing TinyTeX to make sure ~/bin appears in your PATH variable (https://github.com/yihui/tinytex/issues/16).
Execution halted
I need to find a way to verify and trust the certificate chain from yihui.org, as I'm not allowed to bypass the verification with --no-check-certificate.
Thanks in advance for any hint!
Mihai
The default docker image has no certificates installed, therefore there are also no root certificates. That is what is indicated by the error message Unable to locally verify the issuer's authority. You can obtain the root certificates from the package ca-certificates (install it via apt-get).
Problem description:
I am trying to install Netbeans 12.0 on Debian "Buster", using the official Netbeans installer. Though the following exception occures:
No protocol specified
Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "main"
Maybe you know a solution for the above problem?
Thank you for your time!
Note: I know that I could install Netbeans 12.0 as a snap package, but here I'm not interested in it.
Followed steps:
1) In Terminal, I logged-in as the root user:
$ su
Password: ***
2) I installed the package openjdk-11-jdk:
$ apt install default-jdk
3) Then I checked the java version:
$ java --version
openjdk 11.0.7 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Debian-3deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Debian-3deb10u1, mixed mode, sharing)
4) I downloaded the three files specified by the official documentation (Downloading Apache NetBeans 12.0) into "~/Downloads" folder:
The installer file ("Apache-NetBeans-12.0-bin-linux-x64.sh") from the offered mirror site;
The PGP ASC file ("Apache-NetBeans-12.0-bin-linux-x64.sh.asc");
The KEYS file.
5) I navigated to the "Downloads" folder:
$ cd Downloads
6) I set the execute permission on the Netbeans installer file:
$ chmod +x Apache-NetBeans-12.0-bin-linux-x64.sh
7) Because the Netbeans documentation specifies this:
Officially, it is important that you verify the integrity of the
downloaded files using the PGP signatures (.asc file) [...]. The PGP
signatures should be matched against the KEYS file which contains
the PGP keys used to sign this release.
I followed the two steps (the ones using gpg) that they are providing in their link, in order to verify the integrity of the installer:
7.a) Importing KEYS file:
$ gpg --import KEYS
gpg: Schlüssel B4C1940FEA9364F1: "Jan Lahoda (Key for signing Apache NetBeans & co. releases.) <jlahoda#apache.org>" nicht geändert
gpg: Schlüssel 13E9F7AE3A4FD551: "geertjan#apache.org (Key for signing Apache NetBeans & co. releases.) <geertjan#apache.org>" nicht geändert
gpg: Schlüssel CF7BA0AB1CCF4647: "Emilian Marius Bold <emi#apache.org>" nicht geändert
gpg: Schlüssel B2BF814FA145CB2D: "Laszlo Kishalmi (CODE SIGNING KEY) <lkishalmi#apache.org>" nicht geändert
gpg: Schlüssel 4A2601CEDA9382F3: "Eric Barboni (Signing Key) <skygo#apache.org>" nicht geändert
gpg: Schlüssel 3703AC389A12A9D4: "Neil C Smith <neilcsmith#apache.org>" nicht geändert
gpg: Schlüssel 57D5896CD86C1320: "Reema Taneja (Code Signing Key) <rtaneja#apache.org>" nicht geändert
gpg: Schlüssel E860B148D27236F9: "Jaroslav Tulach (Key for signing Apache NetBeans & co. releases.) <jtulach#apache.org>" nicht geändert
gpg: Schlüssel 6FA863B0C32A18B1: Öffentlicher Schlüssel "Arunava Sinha (CODE SIGNING KEY) <arusinha#apache.org>" importiert
gpg: Schlüssel 3ED477750C09D18D: Öffentlicher Schlüssel "John McDonnell (CODE SIGNING KEY) <johnmcdonnell#apache.org>" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 10
gpg: importiert: 2
gpg: unverändert: 8
7.b) Verifying the signature:
$ gpg --verify Apache-NetBeans-12.0-bin-linux-x64.sh.asc
gpg: die unterzeichneten Daten sind wohl in 'Apache-NetBeans-12.0-bin-linux-x64.sh'
gpg: Signatur vom Di 09 Jun 2020 17:50:58 CEST
gpg: mittels RSA-Schlüssel 8FE1C26F15E0320E740BAED84A2601CEDA9382F3
gpg: Aussteller "skygo#apache.org"
gpg: Korrekte Signatur von "Eric Barboni (Signing Key) <skygo#apache.org>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = 8FE1 C26F 15E0 320E 740B AED8 4A26 01CE DA93 82F3
8) In the end, I executed the installer:
$ sh Apache-NetBeans-12.0-bin-linux-x64.sh
Configuring the installer...
Searching for JVM on the system...
Extracting installation data...
Running the installer wizard...
No protocol specified
Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "main"
I also tried with "bash" command:
$ bash Apache-NetBeans-12.0-bin-linux-x64.sh
and with "./":
$ ./Apache-NetBeans-12.0-bin-linux-x64.sh
Unfortunately, the result is the same each time:
No protocol specified
Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "main"
Update:
#Kryštof Vosyka gave the working solution: to install Netbeans 12.0 as the current user, not as the root user.
In order to apply his solution, all the above installation steps are to be followed, with the exception of step 6 (setting the execute permission on the Netbeans installer file).
I had the same problem, and solution is quite simple:
Don't start the installation as root.
The installer is graphical and root user cannot really open windows for your user, thus failing.
No idea how to install it for all users, though.
I'm adding a second node to a single-node cassandra cluster, and getting a stack trace on the second node:
ERROR 18:13:42,841 Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193)
at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:446)
at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:504)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
java.lang.RuntimeException: Unable to gossip with any seeds
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193)
at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:446)
at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:611)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:504)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:378)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
Exception encountered during startup: Unable to gossip with any seeds
ERROR 18:13:42,885 Exception in thread Thread[StorageServiceShutdownHook,5,main]
java.lang.NullPointerException
at org.apache.cassandra.gms.Gossiper.stop(Gossiper.java:1270)
at org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:572)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.lang.Thread.run(Thread.java:744)
There are other SO questions with this same issue, but none of the answers have worked for me:
Apache Cassandra: Unable to gossip with any seeds
new cassandra node can't gossip with seed
Datastax Enterprise is crashing with Unable to gossip with any seeds error
I'm running Cassandra 2.0.8 and jdk 1.7.0_51 on both nodes. One node is hosted at DigitalOcean, the other at Linode. I've tried
configuring them as the same datacenter and as different datacenters in cassandra-rackdc.properties, it makes no
difference. I've tried listen_address and broadcast_address blank and hardcoded, makes no difference. I did limit the
list of cipher suites to stop a flood of log messages about missing cipher suites. From the stock cassandra.yaml, I've changed
the following entries, excluding entries related to concurrent writes and compaction. For the sake of this question, wherever
there's a hardcoded ip address in the config, I've replaced those with . Each box has a firewall, but I've tried it with
the firewalls disabled. I've also tried it with ''internode_encryption: none'' and the result is the same. I've used telnet
and netcat to confirm that each host can connect to the other's port 7000 and 7001.
on the original host:
- seeds: "<host1>"
listen_address:
broadcast_address:
endpoint_snitch: GossipingPropertyFileSnitch
internode_encryption: all
cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
on the new host:
- seeds: "<host1>"
listen_address:
broadcast_address:
endpoint_snitch: GossipingPropertyFileSnitch
internode_encryption: all
cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
Edit:
Also, using netstat I can see that the new server successfully establishes a tcp connection to port 7001 of the original server.
Edit:
Okay, next day. I've upgraded to java 1.7.0_60 on both machines. Gossip now works with internode_encryption: none. I very much doubt the new result is related to the change in JDK; it's more likely related to some carelessness in scrubbing directories or the like.
I've commented the line in each config file that lists ciphers. Gossip still fails in the same way with internode_encryption: all. The seed node's logs are clean, but the other node logs Filtering out TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it isnt supported by the socket repeatedly until gossip fails. I think the log entry is related to the failure. Why one logs this and the other not, I don't know. They're both debian running the same jdk version.
Edit:
Installing the JCE on both nodes made the filtering warning go away. Still no encrypted internode communication at this point.
Edit:
With debug turned on, the seed node logs:
DEBUG 22:44:57,409 Error reading the socket d862c40[SSL_NULL_WITH_NULL_NULL: Socket[addr=/10.128.139.94,port=60611,localport=7001]]
javax.net.ssl.SSLHandshakeException: no cipher suites in common
I've pretty carefully created the certs for both servers, following the instructions at http://www.datastax.com/documentation/cassandra/2.0/cassandra/security/secureSSLCertificates_t.html?scroll=task_ds_c14_xjy_2k.
It's now working using either unencrypted or encrypted communications. Encrypted communications started working after installing the JCE extensions on both servers, and making a change in certificate generation. The Datastax instructions for preparing server certificates for Cassandra 2.0 drops a parameter that was present in their Cassandra 1.2 instructions. Including the parameter seemed to make the difference. The additional parameter is -keyalg RSA:
Seed server:
keytool -genkey -alias prod01 -keystore .keystore -keyalg RSA
keytool -export -alias prod01 -file prod01.cer -keystore .keystore -keyalg RSA
Other server:
keytool -genkey -alias prod00 -keystore .keystore -keyalg RSA
keytool -export -alias prod00 -file prod00.cer -keystore .keystore -keyalg RSA
Then, make sure both servers have both certs, and use them to create a trust store using these commands on both servers:
keytool -import -v -trustcacerts -alias prod00 -file prod00.cer -keystore .truststore
keytool -import -v -trustcacerts -alias prod01 -file prod01.cer -keystore .truststore
chmod go-rwx .keystore