Wednesday, April 28, 2010
Will your OAM installation fail in July 2010?
Is your OAM installation setup in simple mode? Then chances are your installation is going to break on July 25, 2010. You may have heard a faint ticking every time you got near one of your OAM machines, but never had a chance to figure out where this impending failure was going to come from. As you know,according to Mayan Calendar, in 2012 in simple mode OAM generates certificates for you using the simpleCA root CA (tools\openssl\simpleCA). This root certificate is also used to complete the chain of trust when establishing SSL connections.
But did you know that root CA certificates expire? The OAM certificate expires Jul 25 18:03:57 2010 GMT after which your OAM components will no longer be able to communicate with each other
How do I fix this?
Luckily the fix is extremely easy.
If you have an account for support.oracle.com, log in and search for ID 811105.1, which will instruct you to download a new cacert.pem and place it in all your simpleCA folders. Don't forget to include any AccessSDK installations, and make sure the new cacert.pem has the correct permissions.
If you don't have an account with support.oracle.com, then the release notes (bug 8556756) for OAM have instructions for extending the life of the Simple mode certificate. Once extended you can copy the new cacert.pem everywhere that it's needed and restart all components.
How do I know if I am affected?
You can browse to tools\openssl and use the openssl command to check the expiration date of the certificate.
openssl.exe x509 -in simpleCA\cacert.pem -noout -enddate
notAfter=Jul 25 18:03:57 2010 GMT
Oracle says the expiration date is July 5th, 2010 in their release notes. What is the real date?
Yes it does say that and we're not sure why. Feel free to update your cacert.pem prior to July 5th - no need to wait until the last minute.
What errors might I see if I did nothing?
WebGate protected pages will say they can't contact the access server.
You may see webgate errors like
2010/07/26@18:03:00.718000 3728 3240 CONN_MGMT ERROR 0x00001C08 \Oblix\coreid\palantir\aaa_client\src\watcher_thread.cpp:84 "NAP initialization failed"
2010/07/26@18:03:00.718000 3728 3256 CONFIG INFO 0x0000182C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:865 "ObAccessException_ENGINE_DOWN" raw_code^301
or if your certificate permissions are wrong
2010/07/26@18:04:59.796000 3712 300 ACCESS_SDK FATAL 0x0000181C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:422 "ObAccessException_NOT_INITIALIZED" raw_code^204
2010/07/26@18:04:59.796000 3712 300 ACCESS_GATE FATAL 0x00001520 \Oblix\coreid\palantir\webgate2\src\iisentry_web_gate.cpp:183 "Exception thrown during WebGate initialization" Error^Oracle AccessGate API is not initialized.
Permalink posted by Patrick @ 4:23 p.m. 
Comments:
<< Home
My OAM 10.1.4.3 installation reports "notAfter=Mar 28 12:57:22 2024 GMT", so apparently this is addressed if you did a fresh installation of 10.1.4.3
This occurred to my project today. Apparently, our issue is not with OAM itself but rather on Webgate. There are some applications that installed Webgate pre-10.1.4.3 version.
This is scary, imagine all applications protected by webgate are not able to load with "engine down" error today all at once.....
This is scary, imagine all applications protected by webgate are not able to load with "engine down" error today all at once.....
# posted by 
: 2:16 a.m.
: 2:16 a.m.
Thanks a lot for your post. It saved me from a long, painful support call with Oracle. I can't believe that this was not communicated directly with their customers!
Post a Comment
# posted by : 2:46 p.m.
: 2:46 p.m. << Home
