http://www.trumbleshoot.com/home/announcements/nzlibraryerrorsinoraclehttpserver
I ran into the same problem when working with OHS 11.1.1.6. This post helped resolving it. Many thanks to Johnathon for that!
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
ohs1.log
[OHS] [NOTIFICATION:16] [OHS-9999] [core.c] [host_id: trumble-web] [host_addr: x.x.x.x] [pid: 1760] [tid: 47526511683200] [user: root] [VirtualHost: main] Oracle-Application-Server-11g/11.1.1.6.0 Oracle-HTTP-Server (Unix) mod_ssl/11.0.0.0.0 OtherSSL/0.0.0 mod_plsql/11.1.1.0.0 mod_onsint/2.0 configured -- resuming normal operations
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] nzos handshake error, nzos_Handshake returned 29039(server HOSTNAME:9999, client 127.0.0.1)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1132067136] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1132067136] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
This infuriating message repeats over and over, and the OHS instance continuously cycles itself. I tried adjusting the cipher suites on all of my virtual hosts (thanks for the awesome hint), but naturally that didn't make any difference. Firewalls were also set up correctly, and I even reverted back to the default SSL wallet.
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
httpd.conf
{..snippet..}
Listen 127.0.0.1:7890
{..snippet..}
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
No comments:
Post a Comment