OO 10.50 to SA 10.21 - unrecognized_name SSL error
Attempting to use OO 10.50 to connect to SA 10.21 core to run get_sa_version operation, receiving the following error:
Operation Failed! Failed to retrieve the version of given SA. (Failed to connect to the SA. javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name)
We are passing correct credentials through the operation. This seems to be a known problem with self-signed certificates, which the SA core has. Is there a workaround to this? Googling seems to indicate that a change to either the java opts to allow SNIE extensions to be disabled is the path forward, but wondering if that's applicable here.
I have exactly same problem on HPOO 10.20 againt SA 10.21.
I will probably swith to HPOO 10.60 in near future and see if problem still exists there. However it would be nice to have a fix instead of restarting HPOO every time.
Following up to myself: appears related to the use of self-signed certificates, any self-signed certs.
When I added as an input
x509HostnameVerifier with a constant value of allow_all
I could retrieve the SA version mostly reliably.
Setting this input is a terrible idea. It at least allows me to work around the problem while I get real certificates installed.
If I go it right
You need to take the SA certificate (notice the hostname for which it was generated), put it in central trustore, and whenever you access the sa from OO operation - make sure you access with the hostname that you observed in the SA certificate.
Let me know if it works.
PS: When I say put it - I mean the certificate. when I say notice the hostname I mean: Issued to field.
Thanks for the reply. Yes, that's what my next step was, I was trying to understand how I could do something like build a HTTP/2 operation without needing to install the certificate into the OO trust store right away - Proof of Concept and all of that - and then applied it to work around my current problem that my new OO10 environment was complaining about certificates.
I know there is documentation on adding certificates to OO for OO itself, but is there any documentation on when to add a certificate to the truststore for a platform other than OO itself? I don't recall seeing that anywhere - maybe this is a topic for an OO webinar?
The process you are referring is somehow similar to what is explained in "Importing a CA Root Certificate to the Central TrustStore" of the Security and Hardening guide which is here
As and example you should add the SA cer to the central.trustore so that OO will trust that SA server.
As for the webinar - it makes sense and I will write it down.
If you can take the survey I will appreciate it too so that we can easily track all the responses on topics and be able to come back to the person who raised the topic for more details.
I've run into this same issue before, but it didn't have anything to do with certificates. Instead, it was related to having multiple slices, and httpProxy forwarding requests to another slice (part of SA's in-built load-balancing). When this happens, the server name changes, hence the "unrecognized_name" error. To simplify, you hit server A for your request, but it's actually processed on server B, and there is a name mismatch between the two.
For me, this wasn't an issue on OOv9, only OOv10. So if you are running OOv10 and one or more cores with more than one slice each, this may be your issue.
Here is the fix: On each slice in your core(s), edit /etc/opt/opsware/httpsProxy/httpd.conf and right after the <VirtualHost *:4433> line, add this:
So the file should look something like this:
# CMM 2016.10.30 - OOv10 SA Ops Fail w/ SSLProtocolException: handshake alert: unrecognized_name
service opsware-sas restart httpsProxy
Try that and let me know if it works or not.
Just finished migrating from OO 10.20 to OO 10.60, got the error on new HPOO also (same SA version 10.21).
Have implemented your recommendation, will let you know how it goes during the next couple of weeks.
Thanks for your advice.
We've encountered this same issue in several different versions of OO (currently on 10.51).
As for importing into the Central java key store, I use a tool called portecle. Open source tool w/ a UI for interacting with java key stores: http://portecle.sourceforge.net/
Make sure you call SA by the same name as defined in the Common Name (CN) field of the cert. In our environment it's the fully qualified name of the Core server. If we use anything else (short name, alias etc...) we get the ssl error.