Bug 983630

Elad, can you tell me how are you generating that "sslv3 alert certificate unknown" message? I can't reproduce it. I can reproduce other SSL alerts, but not this one, and all the ones that I reproduce are caught later, after the accept method, and thus are processed correctly.

Anyhow, I think that we may need to modify the accept method of SSLServerSocket to something like this:

    def accept(self):
        # First we need to call the accept method of the raw
        # socket and build a new SSL connection object with the
        # results:
        client, address = self.connection.socket.accept()
        client = SSL.Connection(self.context, client)
        client.addr = address

        # Now perform the SSL setup and log errors including the
        # address of the remote client:
        try:
            client.setup_ssl()
            client.set_accept_state()
        except:
            logging.error('client %s', address, exc_info=True)
            raise

        # Finally wrap the connection so that it mimics a
        # socket as the XMLRPC server expects:
        client = SSLSocket(client)

        return client, address

(In reply to Juan Hernández from comment #1)
> Elad, can you tell me how are you generating that "sslv3 alert certificate
> unknown" message? I can't reproduce it. I can reproduce other SSL alerts,
> but not this one, and all the ones that I reproduce are caught later, after
> the accept method, and thus are processed correctly.
> 
> Anyhow, I think that we may need to modify the accept method of
> SSLServerSocket to something like this:
> 
>     def accept(self):
>         # First we need to call the accept method of the raw
>         # socket and build a new SSL connection object with the
>         # results:
>         client, address = self.connection.socket.accept()
>         client = SSL.Connection(self.context, client)
>         client.addr = address
> 
>         # Now perform the SSL setup and log errors including the
>         # address of the remote client:
>         try:
>             client.setup_ssl()
>             client.set_accept_state()
>         except:
>             logging.error('client %s', address, exc_info=True)
>             raise
> 
>         # Finally wrap the connection so that it mimics a
>         # socket as the XMLRPC server expects:
>         client = SSLSocket(client)
> 
>         return client, address

It happens when we have 2 engines that are connected by ssl to the same host

according to comment #2 this is not a bug
Moving to CLOSE NOTABUG

(In reply to Barak from comment #3)
> according to comment #2 this is not a bug
> Moving to CLOSE NOTABUG

IMO, having the relevant engine address is necessary in that error.

I'd like to solve this recent regression: if there's a DoS attack on a vdsm (malevolent or unintentional), we'd like to log the IP of the attacker.

Verified on is18
In the end of error message appear message
SSLError: sslv3 alert certificate unknown, client 10.35.161.82

This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0040.html