Re: Callbacks in an CORBA-SSL-only environment

--===============8682577326149900820==
Content-Type: multipart/alternative; boundary="000000000000fb8e1c0654fa1c14"

--000000000000fb8e1c0654fa1c14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Am Mo., 11. Mai 2026 um 11:09 Uhr schrieb Daniel Kr=C3=BCgler <
[email protected]>:

> Hi,
>
> We are currently moving our CORBA server (Based on JacORB) towards an
> SSL-only configuration, i.e. we deactivate the regular CORBA port
> completely and allow only CORBA SSL (via ssliop). Our clients are based o=
n
> OmniORB and we currently try to find an OmniORB configuration that works
> both for a CORBA server which supports (a) both plain CORBA and CORBA SSL
> and (b) only CORBA-SSL [To clarify: The expectation is, that the client i=
s
> connecting via CORBA SSL, but should not know whether the server accepts
> either both CORBA SSL and plain CORBA or only CORBA SSL].
>
> During my experiments I stumbled across the following issue when CORBA
> callbacks are involved (That is: The OmniORB client registers a callback =
on
> the  JacORB  server).
>
> Originally I had the following set in the OmniORB configuration:
>
> clientTransportRule =3D     *   ssl,unix,tcp,bidir
>
> serverTransportRule =3D    *     ssl,unix,tcp,bidir
>
> endPoint =3D giop:ssl::
>                =3D giop:tcp::
>
> (A) My expectation was that under these client settings of  endPoint
> giop:ssl::would be still preferred regardless of the server constraints,
> but that doesn't seem to hold. If the server is configured SSL-only, the
> client callback waits endlessly and is not called (without producing a
> CORBA connection error visible in the omniORB log file even under
> traceLevel=3D40. I found that it is required to set
>
> endPoint =3D giop:ssl::
>
> to ensure that a client callback is called regardless whether the server
> is configured SSL-only or not. Is this behaviour expected and my chosen
> configuration the right one? What is the reason for this?
>
> (B) Then I tested the same scenario using unidirectional connection
> instead of bidirectional configuration (The POA construction was
> correspondingly adjusted programmatically), i.e.
>
> clientTransportRule =3D     *   ssl,unix,tcp
>
> serverTransportRule =3D    *     ssl,unix,tcp
>
> endPoint =3D giop:ssl::
>
> Under these conditions the client callback never becomes called when bein=
g
> connected to a server configured as SSL-only. I'm wondering now, what kin=
d
> of OmniORB setting is required to make callbacks work under such
> unidirectional conditions?
>
> Thanks for any hint,
>
> - Daniel
>

We have now understood the problems that I reported above: They have been
causes by a misconfigured JacORB server. For those experiencing similar
problems: In this server the default configuration of the following
properties was:

jacorb.security.ssl.client.supported_options=3D0
jacorb.security.ssl.client.required_options=3D0
jacorb.security.ssl.server.supported_options=3D0
jacorb.security.ssl.server.required_options=3D0

This alone is not the actual problem, because we overwrote these values
programmatically to the value 20 for each, but only partially! By making
these changes complete no changes in the omniORB setting where needed at
all, we could stay with

endPoint =3D giop:ssl::
               =3D giop:tcp::

Regards,

- Daniel

--000000000000fb8e1c0654fa1c14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">Am Mo., 11. Mai 2026 um 11:09=C2=A0Uhr schrie=
b Daniel Kr=C3=BCgler &lt;<a href=3D"mailto:[email protected]">dani=
[email protected]</a>&gt;:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>We are cu=
rrently moving our CORBA server (Based on JacORB) towards an SSL-only confi=
guration, i.e. we deactivate the regular CORBA port completely and allow on=
ly CORBA SSL (via ssliop). Our clients are based on OmniORB and we currentl=
y try to find an OmniORB configuration that works both for a CORBA server w=
hich supports (a) both plain CORBA and CORBA SSL and (b) only CORBA-SSL [To=
 clarify: The expectation is, that the client is connecting via CORBA SSL, =
but should not know whether the server accepts either both CORBA SSL and pl=
ain CORBA or only CORBA SSL].</div><div><br></div><div>During my experiment=
s I stumbled across the following issue when CORBA callbacks are involved (=
That is: The OmniORB client registers a callback on the=C2=A0
JacORB=C2=A0 server).</div><div><br></div><div>Originally I had the followi=
ng set in the OmniORB configuration:</div><div><br></div><div>clientTranspo=
rtRule =3D =C2=A0 =C2=A0 * =C2=A0 ssl,unix,tcp,bidir</div><div><br></div><d=
iv>serverTransportRule =3D =C2=A0 =C2=A0* =C2=A0 =C2=A0 ssl,unix,tcp,bidir<=
/div><div><br></div><div>endPoint =3D giop:ssl::<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D giop:tcp::</div><div><br></div><div>(=
A) My expectation was that under these client settings of=C2=A0
endPoint=C2=A0 giop:ssl::would be still preferred regardless of the server =
constraints, but that doesn&#39;t seem to hold. If the server is configured=
 SSL-only, the client callback waits endlessly and is not called (without p=
roducing a CORBA connection error visible in the omniORB log file even unde=
r traceLevel=3D40. I found that it is required to set</div><div><br></div><=
div>
<div></div><div>endPoint =3D giop:ssl::</div><div><br></div><div>to ensure =
that a client callback is called regardless whether the server is configure=
d SSL-only or not. Is this behaviour expected and my chosen configuration t=
he right one? What is the reason for this?=C2=A0</div><div><br></div><div>(=
B) Then I tested the same scenario using unidirectional connection instead =
of bidirectional configuration (The POA construction was correspondingly ad=
justed programmatically), i.e.</div><br></div><div>
<div></div><div>clientTransportRule =3D =C2=A0 =C2=A0 * =C2=A0 ssl,unix,tcp=
</div><div><br></div><div>serverTransportRule =3D =C2=A0 =C2=A0* =C2=A0 =C2=
=A0 ssl,unix,tcp</div><div><br></div><div>endPoint =3D giop:ssl::</div><div=
><br></div><div>Under these conditions the client callback never becomes ca=
lled when being connected to a server configured as SSL-only. I&#39;m wonde=
ring now, what kind of OmniORB setting is required to make callbacks work u=
nder such unidirectional conditions?</div><div><br></div><div>Thanks for an=
y hint,</div><div><br></div><div>- Daniel</div></div></div></blockquote><di=
v><br></div><div>We have now understood the problems that I reported above:=
 They have been causes by a misconfigured JacORB server. For those experien=
cing similar problems: In this server the default configuration of the foll=
owing properties was:</div><div><br>
<span><code class=3D"gmail-_ca0qyh40 gmail-_u5f3m5ip gmail-_n3tdyh40 gmail-=
_19bvm5ip gmail-_2rkofajl gmail-_11c819w5 gmail-_1reo1wug gmail-_18m91wug g=
mail-_1dqoglyw gmail-_1e0c1nu9 gmail-_bfhk187e gmail-_16d9qvcn gmail-_syazi=
7uo gmail-_vwz41kw7 gmail-_1i4q1hna gmail-_o5721jtm">jacorb.security.ssl.cl=
ient.supported_options=3D0</code><br><code class=3D"gmail-_ca0qyh40 gmail-_=
u5f3m5ip gmail-_n3tdyh40 gmail-_19bvm5ip gmail-_2rkofajl gmail-_11c819w5 gm=
ail-_1reo1wug gmail-_18m91wug gmail-_1dqoglyw gmail-_1e0c1nu9 gmail-_bfhk18=
7e gmail-_16d9qvcn gmail-_syazi7uo gmail-_vwz41kw7 gmail-_1i4q1hna gmail-_o=
5721jtm">jacorb.security.ssl.client.required_options=3D0</code><br><code cl=
ass=3D"gmail-_ca0qyh40 gmail-_u5f3m5ip gmail-_n3tdyh40 gmail-_19bvm5ip gmai=
l-_2rkofajl gmail-_11c819w5 gmail-_1reo1wug gmail-_18m91wug gmail-_1dqoglyw=
 gmail-_1e0c1nu9 gmail-_bfhk187e gmail-_16d9qvcn gmail-_syazi7uo gmail-_vwz=
41kw7 gmail-_1i4q1hna gmail-_o5721jtm">jacorb.security.ssl.server.supported=
_options=3D0</code><br><code class=3D"gmail-_ca0qyh40 gmail-_u5f3m5ip gmail=
-_n3tdyh40 gmail-_19bvm5ip gmail-_2rkofajl gmail-_11c819w5 gmail-_1reo1wug =
gmail-_18m91wug gmail-_1dqoglyw gmail-_1e0c1nu9 gmail-_bfhk187e gmail-_16d9=
qvcn gmail-_syazi7uo gmail-_vwz41kw7 gmail-_1i4q1hna gmail-_o5721jtm">jacor=
b.security.ssl.server.required_options=3D0</code></span>

</div><div><br></div><div>This alone is not the actual problem, because we =
overwrote these values programmatically to the value 20 for each, but only =
partially! By making these changes complete no changes in the omniORB setti=
ng where needed at all, we could stay with</div><div><br></div><div>
endPoint =3D giop:ssl::<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0=3D giop:tcp::</div><div><br></div><div>Regards,</div><div><br></div=
><div>- Daniel</div></div></div>

--000000000000fb8e1c0654fa1c14--


--===============8682577326149900820==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list

--===============8682577326149900820==--