I installed WebSphere 7.0 and RAD 7.5. Updated WAS to fix pack 11 and update RAD. 7.5.5. latest updates..etc...
I create a server profile.
I start the server.
I turn on global security and use LDAP. (something I have done a billion times)
I don't even attempt to publish an application.
The server constantly debugs out this message every two minutes.
How do you make it stop? I have tried making new keys doesn't work, I blow away the profile and make a new one. Nothing works. Nothing. The server is running at 400 MB without an application installed. Is this supposed to be normal? 400 MB with no app published?
The server profile creation wizard forces this SSL nonsense into the config.
What's really going on here?
I would love to utilize the latest server technology IBM has to offer but it seems to be broken right out of the box, out of the gate. 5 fix packs later and it's still broken.
[8/25/10 8:12:44:896 CDT] 0000000b SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.ibm.jsse2.b.a(b.java:34)
at com.ibm.jsse2.pc.a(pc.java:155)
at com.ibm.jsse2.pc.unwrap(pc.java:104)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:17)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:531)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:291)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
I was wrong. Creating it from either way causes the issue. (running the pmt.bat or through the rad tool).
The real issue was not copying the global security stuff as a security domain. Basically you go to Security > Security Domains > then click the Copy from Global Security option.
This is just crazy. Why not simply have the goofy wizard ask if you would like this to happen also??? IBM infuriates me.
I solve this issue by enabling security in the server screen.
Open the Servers view, double click on the server, expand security, enable "Security is enabled in this server" and provide a user ID + password. After this the problem went away.
For some reason it was disabled even though I enabled it through the admin console.
Its too late but may be it helps others like me :)
Agree with Peter above, its IDE which checks status from server..
You need to add the certificate 'X' i.e. exportedCertificate.cer to JRE keystore. To do this, run this command in a Windows CMD window:
$ keytool -import -file exportedCertificate.cer -storepass changeit -keystore %JAVA_HOME%/jre/lib/security/cacerts -alias myAlias
Certificate 'X' is the default certificate in your Websphere server. You can find and export it through IBM console. Alternative is to hit HTTPS url at browser and export it from browser in DER format.
I found that this solution worked best for me.
http://wiing.fr/websphere-application-server-ssl-error/
The way to fix it is to connect to the administration console,
navigate to: Security > SSL certificate and key
management > Key stores and certificates >
NodeDefaultKeyStore > Personal certificates
Select the default alias and click on renew. Restart WAS.
I recently got that error because the certificate’s beginning date was
set to a date in the future, could not understand what happened to my
configuration…
Your app server is trying to establish a ssl connection on a port that is not ssl. An easy way to see it live is trying to access the admin console using http but using the ssl port.
If you use the standard ports you can try this:
http://localhost:9043/ibm/console/
This error may be caused by your IDE (let it be Rational Application Developer RAD, Rational Software Architect RSA or plain Eclipse), which is trying to update the server status in the "Servers View".
As somebody here already said, the IDE's call to WebSphere Application Server's console fails, because it's malformed:
Unrecognized SSL message, plaintext connection?
Since your IDE tries to update the status regularly, the server prints this error message as often.
What worked in my case, was to remove the server from the "Servers View" (Right click - delete) and add a new one (Right click - new).
In my case, my IDE is not run with IBM's JRE. Since it's eclipse. so i update the eclipse.ini to include
-vm
E:/IBM/WebSphere/AppServer/java/bin/javaw
In most cases, this is due to expired SSL Certificate. Go to:
C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\XXXXXXNode01Cell\nodes\XXXXXXXXNode01
and see key.p12 and trust.p12 files. Check the created/modified date. It will typically be more than 1 year older. This means it's expired as typically above files are valid for 1 year only.
Solution
Delete entire websphere server profile (which will delete everything under C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01 and create a new. this will wipe out key.p12 and trust.p12 files along with other files and create a new key.p12 and trust.p12 files when you create new profile.
Copy key.p12 and trust.p12 from your colleague's machine whose key files(key.p12 and trust.p12) are not expired. You can also use iKeyman tool to renew key.p12.
I also faced this issue . finally sorted out this issue. Below are the steps may helpful.
delete the profiles which you have created earlier.
to view all profiles: IBM/AppServer/bin/manageprofiles.bat -listProfiles
deletion of profiles: IBM/AppServer/bin/manageprofiles.bat -delete ProfileName
Windows-->Start-->Services find any IBM WebSphere servers are running background. try to stop them and restart the server.
Modify your eclipse.ini to explicitly use the IBM JRE as follows:
-vm C:/Program Files (x86)/IBM/WebSphere/AppServer/java_1.7_64/jre/bin/javaw.exe
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.7
-Xms512m
-Xmx6144m
Restart Eclipse and Restart your IBM Websphere Application Server to fix the issue.
Related
I have written a restful API project which is developed using spring boot and I am using the embedded tomcat and running a jar on a linux server.
The APIs are live at:
https://api.arevogroup.com:8089/api/regions
and I can see the verified and correct SSL as well as in the given screenshot.
but I am getting an this exception in the postman when I call these apis.
These APIs are consumed by a Xamrin based app which seems to work all good when consumed using iPhone but gives this same exception when the APIs are accessed via android.
I guess, the way I have generated the ssl certificate has some issues.
I have used a pfx file and my SSL config in properties file looks like this:
###SSL Key Info
security.require-ssl=true
server.ssl.key-store-password=PASSWORD
server.ssl.key-store=classpath:ssl_pfx.pfx
server.ssl.key-store-type=PKCS12
I have 2 questions, if disable the ssl verification, would the communication still be encrypted or not? (man in the middle attack is still possible but the info will still be encrypted, right?).
If not, how can I fix this?
You can't disable the verification of the server certificate. No browser will allow you to do it, except on an exceptional basis (the user must confirm the exception). If the client disables the verification, than the communication will be encrypted (i.e. no passive attack will be possible).
The errors you see are cause by a misconfiguration of your server.
Your certificate chain contains just the certificate for your server and lacks the intermediate certificate CN=Go Daddy Secure Certificate Authority - G2. You need to download it from Go Daddy (it is the one named gdig2.crt.pem) and add it to your keystore.
Refer to this question on how to do it.
Some browsers cache intermediate certificates and are able to verify your site even if one certificate is missing. However you should not rely on it.
security.require-ssl=true
server.ssl.key-store-password=PASSWORD
server.ssl.key-store=keystore.jks
server.ssl.key-store-provider=SUN
server.ssl.key-store-type=JKS
Used the jks file instead of pfx and it worked all good. Thought to share with others too.
I have an application that receives items from a high-speed scanner device. As the items are received, they are written to disk using SQL Compact. The following digitally signed Microsoft DLLs are used:
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
I recieved a performance complain from a customer, and traced the issue using Microsoft Procmon to a TCP Reconnect failure when attempting to contact the site for certificate validation when we make calls to methods in these dlls. At first, I could not recreate the issue locally. After talking to their infrastructure people and developers, I learned that they must use a proxy for internet connectivity. Some of the customer's users (in the test environment) had valid proxy settings, and they got good performance from our application. Naturally when they turned their proxy settings off, the validation could not be done and the performance issue arose.
I attempted to recreate the issue by setting our machine up with false proxy settings to a non-existent machine. On my initial attempt, I still got good performacne from our application, and no attempt was made to contact the internet for cert validation. After looking at the cert's validation chain, I noticed that it derived from the certificate "Microsoft Root Certificate Authority". I then exported and deleted that Cert, and was able to reproduce the issue as determined by a comparison of logs.
I did the following tests:
Test 1:
1. Opened the proxy settings, and enabled them pointing to a non-existent address.
2. Ran a test.
Results: No performance issue.
Test 2:
1. Exported the “Microsoft Root Certificate Authority” cert and moved it to the untrusted folder.
2. Ran a test.
Results: The performance issue occurred.
Test 3:
1. Deleted the “Microsoft Root Certificate Authority” cert.
2. Started a test.
Results: The performance issue began occuring.
3. While the test was in progress and device was hesitating I removed the false proxy settings.
Results: The performance issue disappeared and the application recovered.
Tentative Conclusions:
1. That I can simulate the no internet access condition by providing false proxy settings.
2. If the “Microsoft Root Certificate Authority” cert is installed properly, the .Net infrastructure does not need to access the network to verify the necessary cert.
3. If not, it will attempt to validate via the internet connection.
Nevertheless, when the customer checked the certificates in the "Trusted Roots Certificates" folder of mmc->certificates-local computer. The "Microsoft Root Certificate Authority" certificate does appear there, and it seems to be identical to mine. Yet for some reason the use of the dll's causes certificate validation to attempt to access the internet resulting in a performance issue.
In the customer's situation, eventually devices will be used in production with no internet access.
My question is, is there a setting (registry, or GPO) that might cause certificate validation to always attempt to use the internet, regardless of whether the root certificate of the validation chain is installed in the local computer?
Can a setting be enabled that causes a certificate validation to access the internet to check to see if the root certificate has been revoked, for example?
Please feel free to ask questions if you need more information.
This appears to occur for SQL Server Compact 4.0 on any system with an invalid proxy configuration, as a Certificate Revocation List check is run each time the engine is loaded (which happens on the first call to .Open()).
Solution: To avoid this delay, which probably affects any signed app on the system in question, you must fix the configuration or disable the check. The check can be disabled via UI or via registry settings, as described here: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282
For additionla issues see my blog post here: http://erikej.blogspot.com/2013/08/faq-why-is-opening-my-sql-server.html
I am new to tridion and trying to setup a new instance of tridion 2011. I was able to successfully publish all my requests to file system and broker db. Suddenly it stopped publishing and all requests are stuck in "Ready to transport" mode.
I have already gone through many related threads on this forum, but could not sort out the problem. I am using Widows server 2008, with Jre 1.6 (32 bit and 64 bit both installed). Any pointer to finding the issue will be appreciated.
First thing to check is if your transport service is running.
Second thing I would look at is the config files to make sure the transport service is looking in the same directory that the publisher is storing them. Then see if files are being dropped in the transactions folder on the CM machine.
In our environment this issue arose due to a change in the SSL ciphers supported on our Content Deployer server. We are using the SSHFTP transport protocol and for security reasons the RC-4 cipher suite that had been supported by the CD server was no longer supported. We logged a case with SDL support and they issued Hotfix CD_2011.1.2.2350 which adds support for the stronger ciphers.
Unfortunately, the logs gave absolutely no indication of the issue, even with TRACE level logging.
So if you face this issue and you're using SSHFTP and the other solutions don't work for you, maybe this will help.
I'm about at the end of my rope with Windows Azure Tools and SSL configuration in the ServiceDefinition/ServiceConfiguration files in a cloud project.
At first, I had a web role with RDP enabled (and certificate configured, etc). All that worked for a long time. Then I added an SSL certificate for an https endpoint. It wouldn't deploy because of certificates not being installed in my localmachine/personal store, etc. After messing with it, somehow I've gotten into a bad state where even if I completely remove all configurations having to do with RDP or SSL, I still get this from the emulator:
Windows Azure Tools: Warning: The SSL certificate 'Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption' for endpoint 'HttpsIn' of role 'My.Web' was not found in the local machine's certificate store.
Windows Azure Tools: Warning: Certificate identification setting 'Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption' for role 'My.Worker' specified in the service configuration file is not declared in the service definition file in the Certificate or as part of an SSL endpont
Like I said, there is no such configuration in any of my files, and when there were, they hadn't changed from the time that they worked until this. I tried deleting the dftemp directory where the deployments get placed, I've cleaned and rebuilt the cloud project, I've killed visual studio and the emulator(s), and still always wind up back in the same place.
Has anyone else seen this?
I'm not sure what happened, but after leaving for the day and coming back this morning, I found that a system reboot seemed to clear the issue. I have no idea why, but this seems to have resolved itself.
for first error, you have to remove certificate from certificate section of your service configuration file(cscfg). This certificate is used for encrypting your RDP password.
For second error, I think if you remove above section, it will automatically disappear. Also ensure that you have removed modules RemoteAccess, RemoteForwarder from service definition file(csdef)
As part of a ClickOnce deployment I'm running mage.exe
mage.exe -Sign "manifest file" -CertFile Cert.pfx -Password yepit5right -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll
the certificate comes from Verisign in the first place so using their timestamping service.
This works fine on some machines but not others, and they come back with the very readable error code of -2147012865 which translates to error 12031 - ERROR_INTERNET_CONNECTION_RESET.
I can connect out through IE on that machine to sites such as stackoverflow.com and so the proxy settings which it needs appear to be correct.
Does mage.exe support authenticating proxies? This used to work, over a year ago now, before we had a major outbound proxy change which I think included changing from non-authenticating to using integrated authentication at the proxy layer.
Thanks
Not a great answer but it turns out that mage.exe cannot authenticate through to a proxy when making the request out to the timestamping service.
To get around this restriction I have added the source machine and the target URL to our outbound proxy's "whitelist" of requests that are allowed out without requiring proxy authentication. As you could imaging doing this within a corporate environment where the security team own that list was not a simple task, I much prefer cracking the technical nut.
As soon as this was added mage.exe started behaving as expected, and as it behaves in our test environments which have a non-authenticating proxy.