When I try to start node manager I am getting below error. I am getting this error on remote machine. By the way node manager is running on my local machine without any problem. Both machines have same configuration. Is there any idea?
<SEVERE> <Fatal error in node manager server>
weblogic.nodemanager.common.ConfigException: Unknown key store identity alias or not a key entry alias: DemoIdentity
at weblogic.nodemanager.server.SSLConfig.loadKeyStoreConfig(SSLConfig.java:175)
at weblogic.nodemanager.server.SSLConfig.<init>(SSLConfig.java:100)
at weblogic.nodemanager.server.NMServer.init(NMServer.java:185)
at weblogic.nodemanager.server.NMServer.<init>(NMServer.java:147)
at weblogic.nodemanager.server.NMServer.main(NMServer.java:353)
at weblogic.NodeManager.main(NodeManager.java:31)
You'll want to go look at the wlserver_10.3/common/nodemanager/nodemanager.properties file.
It sounds like your domain isn't set up to use a custom trust store or key store so it defaults to using the "Demo" identity.
In that properties file, verify that
ListenPort=5556
SecureListener=false
You may also want to login to your admin console and verify that all of the settings here are correct:
Environments->Machines-> <your machine name> -> Configuration-> NodeManager
You may want to use Plain instead of SSL.
If you do want to use SSL, I would recommend checking out a tutorial like the following:
http://jvzoggel.wordpress.com/2011/12/16/configuring-ssl-for-oracle-weblogic-and-ofmw/
Old Question. For future users.
It could not able to find the alias in the keystore specified.
Unknown key store identity alias or not a key entry alias: DemoIdentity.
In the nodemanager.properties check the following lines
CustomIdentityKeyStoreFileName=<path_file>/kesytore.jks
CustomIdentityAlias=<AliasName>
I hope you have given as DemoIdentity and it couldnt find the alias in the keystore.jks file.
Make sure you have given correct alias or correct jks file .
To know the list of alias in the jks file
keytool -list -keystore <path_file>/kesytore.jks
Related
I'm trying to set up an OpenLDAP server in a docker container on my local network. I got it set up and connected using Apache Directory Studio and created some posix groups/accounts with no trouble. The problem is, I can add a plaintext userPassword for my users but trying to use any type of encryption scheme results in the error:
entry failed schema check: value of naming attribute 'userPassword' is not present in entry
Other notes about my configuration:
I'm using a self signed certificate using the LAN address to connect over LDAPS
Using the docker image osixia/openldap
I can provide any other configurations if needed.
Normally you would install the ppolicy module and set the "ppolicy_hash_cleartext" variable in slapd.conf to enable password hashing. Since you're using a docker container this will work slightly differently.
Check out the following page from the docker image you are using:
https://github.com/osixia/docker-openldap/issues/208
i have put in /u01/app/oracle/product/fmw/wlserver_10.3/server/lib/
2 files:
-trust.jks
-identity.jks
Then i have changed on Webblogic console, for Admin and managed servers,
the PATH to:
-Custom Identity Keystore
-Custom Trust Keystore
All looks good.
After weblogic restarts all servers are running, but
when i run this command on terminal ps -eaf|grep weblogic
i see this line:
-Djavax.net.ssl.trustStore=/u01/app/oracle/product/fmw/wlserver_10.3/server/lib/DemoTrust.jks
As a result no one of my online interfaces are connecting.
I get the following error:
BEA-382513<con:reason>OSB Replace action failed updating variable "body": {err}FORG0005: expected exactly one item, got 0 items</con:reason>
Can someone help me to correct the path for my Servers so that it would look for trust.jks and not the DemoTrust.jks?
The way to fix this is by setting the flag on "SSL Listen Port Enabled"
thet can be found
Home >Summary of Environment >Summary of Servers >AdminServer -> Configuration/General.
After this we need to go to this view:
Home>Summary of Environment >Summary of Servers >AdminServer >Summary of Servers->Control
Select AdminServer and Click on Restart SSL.
To see if changes bin done we need to execute the command:
ps -eaf|grep weblogic
and look for
-Djavax.net.ssl.trustStore=/u01/app/oracle/product/fmw/wlserver_10.3/server/lib/**trust.jks**
If the end has the trust key file,in my case i called it trust.jks, then the change was performed successfully.
I'd like to be able to go get from my Stash server with a nice URL. My stash server works only over HTTPS. The problem is that my SSL certificate I'm using with stash is self-signed and any go get to my server gets me the following error:
x509: certificate signed by unknown authority
Is there a way to authorize self-signed certificates from go get?
go get -insecure has been deprecated.
As of go 1.14, the correct way to do this is by setting the GOINSECURE environment variable to a comma-separated list of domains from which you'd like to ignore the certs.
E.g. Setting in within ~/.zshrc (if zsh shell)
GOINSECURE=example.com
Then you will be able to install the packages like:
go get example.com/some/pkg
Use go get -insecure https://xxxxx.
From go get -h:
The -insecure flag permits fetching from repositories and resolving
custom domains using insecure schemes such as HTTP. Use with caution.
I'm not familiar with certificates and openldap. I'm trying to port someone elses work from an older OS to CentOS-6 with openldap-2.4.23. On the old OS, an ldap connection worked without issue. Now on CentOS-6, I get the following error when doing a simple bind:
TLS error -8179:Peer's Certificate issuer is not recognized.
My /etc/openldap/ldap.conf has a single line:
TLS_CACERTDIR /etc/openldap/certs
I tried commenting out that line and putting the following into the file but that didn't change the error message I received.
tls_reqcert allow
I also tried putting only the following line in ldap.conf but that didn't change the error. I tried this based on information found in this question.
LDAPTLS_CACERT /etc/ssl/certs/ca-bundle.crt
I copied files into the following directories:
/etc/pki/tls/certs/ca.crt
/etc/pki/tls/certs/server.crt
/etc/pki/tls/private/server.key
I have no choice but to use openldap-2.4.23. Any idea what is causing this error or what I can do to troubleshoot?
Thanks in advance.
SP
As per http://www.zytrax.com/books/ldap/ch6/ldap-conf.html TLS_CACERT should point to the file containing the CA cert that the client will use to verify the certificate. You need to make sure the your servers CA [The CA that signed your server certificate] is present in the file that TLS_CACERT points to[in your case /etc/ssl/certs/ca-bundle.crt.
I had the same error. In my case the reason was, that my client had the wrong certificate in /etc/ipa/ca.crt. To fix this, I just copied /etc/ipa/ca.crt from the KDC server to the client and the error disappeared.
Depending upon the environment, OpenLDAP may completely ignore the value set for TLS_CACERTDIR because evidently GnuTLS doesn't support that type of certificate store.
From the man page for ldap.conf(5)
TLS_CACERTDIR <path>
Specifies the path of a directory that contains Certifi‐
cate Authority certificates in separate individual files.
The TLS_CACERT is always used before TLS_CACERTDIR. This
parameter is ignored with GnuTLS.
In my case, I suspect that GnuTLS is in use, so TLS_CACERTDIR simply does nothing. Using TLS_CACERT pointed to a file containing the certificate of my server's signing CA seems to have done the trick.
I think https://serverfault.com/questions/437546/centos-openldap-cert-trust-issues is a much more complete answer.
I'm making an cfhttp to connect to an encrypted page. Seems to work fine for some sites.
I/O Exception: Name in certificate `pro.test.com' does not match host name `go.test.com'
Is there a workaround to trust this certificate even if the host name doesn't match?
Think this is more Java question, and workaround should be affecting the JRE.
Not sure if this will work in your case, but possible solution is to import this certificate into the JRE keystore.
Generic description can be found at Sun website. Though process is pretty simple.
First you should navigate the needed HTTPS URL with your browser and export the cert using SSL properties (don't remember how it is done in IE, but in Firefox something like Security > View cert > Details > Save as -- still not sure because using non-English licalization), any X.509 type should work.
Next you should import it using keytool. Navigate to the current CF JRE's bin, execute the following command (replace arguments with your values) and restart CF:
keytool -keystore <path to keystore> -import -file <path to certificate> -alias <alias>
BTW, there is a UI tool for this, but I haven't used it so can't say if it works fine.
The sites that are probably working have a valid SSL Certificate from a trusted authority.
If you have control of pro.test.com, the preferred answer would be to get a valid cert for pro.test.com installed. But if that is not possible for some reason, I see two other options:
1) Do a try/catch where you try to connect via https, and fall back on http in the event of an SSL error. Obviously this would eliminate encryption for the failed connection.
or
2) Use Sergii's solution to import the key for that site into the Java keystore.
If go.test.com is just a development server, in that case you can create a self-signed certificate and import it into Java keystore. That way you can save up on cost by not paying to CA and get a quicker turnaround to resolve the issue