[Spacewalk-list] Subject Alternate names

[Olly Mason]

To help anyone else who comes across this, it's not necessarily an ssl
error. The JabberClient.connect() function in jabber_lib.py raises a
SSLDisabledError in too many circumstances - even if the connect retry loop
exits due to a jabber issue that is not related to the transport layer.

The problem as I understand it is that osad/osa-dispatcher will not work
across multiple domains. Both client and server will connect to and
send/receive messages over jabber on a named domain, connecting to either
c2s or s2s which will route to a jabber sm process. Each jabber sm process
(and there's only one used in spacewalk) will only work on one domain.
Therefore, messages must be sent and received on the same domain. It would
appear from experimentation that this domain needs to match the name of the
Spacewalk server. i.e. you cannot have a spacewalk server that thinks it is
called "spacewalk", and connect osad/osa-dispatcher to "spacewalk-mng",
even if you:
* change jabber connection URLs in config files on client and server
* disable the common name check in osad's JabberClient.verify_peer() that
doesn't take SANs into account, on both osad and osa-dispatcher
* change the jabber c2s, s2s and sm configs and generate SSL certs to cover
SANs
When a message comes from osa-dispatcher to the osad clients, exceptions
will be raised. In our case we have decided that the issue is not worth
pursuing further. Hostfile hacks are possible but dirty. We will instead
work with the constraints given.

Regards,

Olly


On 28 October 2015 at 07:39, Olly Mason <ollymason at gmail.com> wrote:

> Hi,
>
> I have a question about osad and subject alternate names and can't find
> an answer in satellite or spacewalk docs.
>
> We have a spacewalk 2.4 install with multiple NICs
> - the primary FQDN resolves to a public NIC and spacewalk is setup with
> that name
> - a second DNS name, spacewalk-mng resolves to the management NIC.
> Up2date conf files refer to the spacewalk-mng full domain name
> We are using certificates generated by rhn-ssl-tool, using --set-cname
> to add a SAN matching the second domain name into the csr and cert
> generated from that. The clients are correctly trusting the CA cert used
> to generate the server cert.
>
> This works fine for yum plugin, but osad doesn't start - it refuses to
> connect with a SSLDisabledError generated in jabber_lib.py. It appears
> that the client doesn't like SANs? We need to be able to connect over
> both NICs (both DNS names) with TLS preferably, and don't want to do a
> hosts file hack. Is there any way of altering client config or code such
> that a valid cert using SANs is still usable?
>
> I have tried disabling the SSL cert Common Name check in the code, but
> regardless osad won't connect.
>
> Regards,
>
> Olly
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20151030/b38a919c/attachment.htm>