Can't install Apache web agent for OpenAM implementation - windows

I have previously installed a J2EE policy agent and implemented SSO with it. Now I was trying to do the same with a web policy agent, but I am stuck. When I am trying to install the Apache22 web agent, I am being asked to provide some inputs. The second input is the URL of the OpenAM server. In my case, that is http://openam.example.com:9080/openIdp2 . But whenever I enter this value, the installation gets stuck. I have taken the following steps:
I have ensured that the openAM server is up and running.
I have created a centralized web agent in the openAM server.
I have installed OpenSSL and included the libeay32.dll, ssleay32.dll files in the agent/lib folder( I don’t have the ‘dll files missing’ error)
I have added the agent/lib folder in the environment variable path.
I have done all this and yet I am getting nowhere. I had used these same steps when I had configured the J2EE agent earlier. The OpenAM server is deployed in Tomcat on my local machine.
This is the configuration I am using:
Http server: Apache 2.2
Web Policy Agent:
i)Release: 4.0.0
ii)Platform: Apache 2.2
OS: Windows 10 64 bit
When I tried installing using the ‘silent’ option, I was asked to provide all the input. I did that and now the console is just stuck with the ‘Validating…’ message. It has been in that way for some time. The installation doesn’t stop, it just freezes.
Can you tell me what I might be doing wrong?
Can anyone help me out?

I had a similar issue a while back and was advised to step-back to the 3.3.4 Agent. Since there were no features I needed in 4.0 that were not in 3.3 I did and have not looked back. Also, consider that the latest agent available is 4.0.1. So either go back to 3.3.4 or consider trying 4.0.1.

Related

SSL/TLS Handshake error while calling Azure Vision API

I have a spring boot based microservice in which I am using Microsoft Azure Computer Vision API to read data from a PDF file. After containerizing the microservice, the container works fine and I am able to send/receive data to/from Computer Vision API on my machine. But, when I run this container on an Azure based Linux Virtual Machine, the container cannot communicate with the Computer Vision API and throws exception java.lang.RuntimeException: javax.net.ssl.SSLKeyException: RSA premaster secret error. Also, the spring-boot jar is able to communicate with Azure on VM and throws no such exception.
Do you think I need to pass any self-signed certificate to the container for it to be able to communicate smoothly?
I think the biggest advantage of using these containers is that it makes the code platform independent. So, why is this error thrown only on Azure VM and runs completely fine on my machine? Please advise.
java.lang.RuntimeException: javax.net.ssl.SSLKeyException: RSA premaster secret error
On local computer was working fine but when run the container on Azure Linux VM it is not working so there might be compatibility issue between Linux VM and Java JRE’s.
Based on above error the solution is Just remove the updated java version from your server Classpath and try to install the old java version
Please refer this link had the same discussion over here related to above error : https://community.oracle.com/tech/developers/discussion/1533888/another-rsa-premaster-secret-error
Second, try to set the SSL/TLS parameters in the java panel because An SSL certificate is a bit of code on your web server that provides security for online communications. When a web browser contacts your secured website, the SSL certificate enables an encrypted connection. It's kind of like sealing a letter in an envelope before sending it through the mail.
Supported SSL/TLS versions by JDK version
I was able to find out what the error was. There was nothing wrong with the JDK/JRE setup. The issue arose due to the version of docker engine installed on the Azure VM.
Azure based computer vision APIs required server to be TLS1.2 compliant, whereas the version of the docker engine installed on my machine was older and did not support TLS1.2. I was able to fix it after upgrading the docker engine to the latest version.

how to set up a standalone yubikey otp validation server in windows?

I want to set up a standalone yubikey otp validation server in windows.Can anyone please help me with the steps I can follow in windows.
Thanks.
I have just written a standalone validation server in Python with Django. I did not test it on Windows, but given the dependencies it requires, there shouldn't be any problem.
The official YubiKey Validation Server (YK-VAL) installation steps apply to any GNU/Linux-like system and Ubuntu 14.04 LTS is recommended. A Windows setup guide is not available.
Instead of setting up your own validation server, you could use Yubico's YubiCloud web service for verifying OTPs.
Additionally, if you are looking for an OATH certified TOTP and/or HOTP validation server you can find a list on the OATH site.
Edit:
There is a guide for Self-hosted OTP validation available. But again, the guide uses Ubuntu as a platform, not windows.

Shibboleth Service Provider 2.3.8 - Error 1053: The service did not respond to the start or control request in a timely fashion."

I am trying to build up a testing environment in which I could manage the login to my web application using Shibboleth. I managed to configure and install Shibboleth IdP (2.3.8) under Tomcat 6 and now I am trying to install and configure Shibboleth Service Provider (2.5.2). I managed to install the software but when I try to start the Shibboleth SP service (I am using Windows XP SP3) It returns the error in the title.
I'm following instruction from Shibboleth official wiki step by step but I can't figure out the cause of this error.
I am completely new to this kind of technology so keep in mind that I could miss something big :D
Could you guide me in troubleshooting this kind of problem?
I already tried to raise the timeout time putting a registry key but It doesn't seem to solve the problem.
I found myself a solution.
Sorry for my silly question but I hope It could be of help for someone else.
It seems that incompatibility issues between Shibboleth 2.3.8 and Windows XP SP3 prevents It to be installed. I managed to install the SP downloading Shibboleth 2.3.1 SP from Shibboleth's archive.

SSLHandshakeException republish error with WebSphere 8.5 using Eclipse Mars

I am using WebSphere Developer Tools for Eclipse on Mars SR1. I am trying to republish my application on a remote WebSphere 8.5 server. I am running into a SSLHandshakeException error when I try to do an incremental publish.
A "Problem Occurred" dialog pops up with the following details:
The publish encountered some problems and the application may not have
been installed or it may have been successfully installed but was
unable to start. Removal of the following application is completed:
WebAppEAR Removal of the following application is completed:
WebAppEAR Failure uploading archive to server: Upload retry limit
exceeded for file
C:\Users\Administrator\workspace.metadata.plugins\com.ibm.etools.wrd.websphere.core\tmp1455916474993\TestEAR.ear.
Exception: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h:
PKIX path building failed:
java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.;
The only way I can republish my application is to remove it from the server and re-add it.
This is currently a known problem with using WebSphere Application Server on Eclipse Mars with WebSphere Developer Tools. The technote below explains what's causing this problem and a few ways work around it.
IBM Technote: http://www-01.ibm.com/support/docview.wss?uid=swg21976357
Essentially, in Mars SR1 an EPP logging plugin was added, which conflicts with WebSphere Developer Tools. This affects the republishing on WAS V7, V8 and V85 using a secure profile with non-loose configuration (Run server with resources on Server). This includes remote servers, which always run with non-loose configuration and local servers that have that option enabled.
If you choose to disable the EPP logging plugin, please refer to the link below for the latest updates. Also, for those who are using Mars v2 now, please be aware the VM argument has changed slightly after Aeri v2 was introduced.
https://wiki.eclipse.org/EPP/Logging
Also, if you are using an existing workspace and the plugin wasn't disabled, you will have to delete the plugin directory manually. The folder is called "org.eclipse.epp.logging.aeri.ide.server" and it is located here: "workspace/.metadata/.plugins/".
It happens to me whenever I use add or remove projects option to remove the projects and add it back again. When we remove the project from server using eclipse sometimes it won't get remove from actual server. So when we add back again we get this exception. So make sure the project is uninstalled from server admin console when you remove it from server. If it is not, then uninstall forcefully from admin console.

all publish requests are stuck on "Ready to transport" status

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.

Resources