db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2803) SSL certificate authentication succeeds unexpectedly
Date Mon, 25 Jun 2007 16:20:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507913

Rick Hillegas commented on DERBY-2803:

Thanks, Bernt! I have looked at the zip file of html output and I think that this is much
easier to understand. I have some comments on the documentation.


1) I think that the title of this section should be changed to something that suggests why
a user would be interested in consulting this section. Perhaps something like this: "Wire
Encryption and Peer Authentication". Right now, the title "SSL/TLS" seems like a statement
of the solution rather than the problem. I think that the user is more interested in the problem

2) Along the same lines, I think that the section should start out with an introductory sentence
or paragraph focusing the reader's attention on the problem rather than the solution.

3) On the same page: I think that the sentence about CA certificates deserves its own paragraph.
I understand that you can't go into a detailed explanation of certificates and signing authorities
However, it would be helpful if you could at least indicate that you are referring here to
the situation in which a 3rd party is vouching for the identity of the other end of the connection.

4) "Key and certificate handling": I would recommend rewriting the first paragraph as follows:
"For SSL operation, the server always needs a key pair. If the server runs in peer authentication
mode (the server authenticates the clients), then each client needs its own key pair. In general,
if one end of the communication wants to authenticate its partner, then the first end needs
to install a certificate generated by the partner."

5) "Starting the server with SSL/TLS": I would recommend renaming the "Starting the server
with client authentication" subsection to be "Starting a server which authenticates clients"
and I would reword its first paragraph as follows: "When the server's SSL mode is set to peerAuthentication,
then the server authenticates its client's identity in addition to encrypting wire traffic.
In this situation, the server's trust store must contain a certificate for each client which
will connect."

6) "Running the client with SSL/TLS": Similarly, I would rename "Running the client with server
authentication" to be "Running a client which authenticates the server" and I would reword
the first sentence of this section as follows: "If the client wants to authenticate the server,
then the client's trust store must contain the server's certificate."

> SSL certificate authentication succeeds unexpectedly
> ----------------------------------------------------
>                 Key: DERBY-2803
>                 URL: https://issues.apache.org/jira/browse/DERBY-2803
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation, Security
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Bernt M. Johnsen
>             Fix For:,
>         Attachments: DERBY-2803.diff, DERBY-2803.stat, DERBY-2803.zip
> The following bug report may simply be pilot error. I confess that I am having a hard
time understanding the user documentation for this feature. The user documentation is found
in the Derby Admin guide in the section titled "SSL/TLS". My confusion arises from the fact
that sometimes the documentation talks about 3 SSL states (none, basic, peer) and sometimes
the documentation talks about 4 SSL states (none, basic, client certificate, server certificate).
> I tried running an experiment in which the server was setup for "Basic SSL encryption":
> 1) I successfully connected to the server when the client was setup for "Basic SSL encryption".
This I expected so good.
> 2) I also successfully connected to the server when the client was setup for "peer (server)
authentication". This confused me because the client url was requesting peer authentication
but the server was booted with just basic ssl authentication. That is, the client url requested
"ssl=peerAuthentication" but the server startup line requested "ssl=basic". I was surprised
that the two sides of the connection didn't have to agree on how much authentication was going
to be done.
> 3) I also successfully connected to the server when the client was setup for "peer authentication
on both sides". This really confused me: It seemed to me that there were 2 certificates involved,
but the server, via its startup properties, should only have been aware of one of these certificates,
viz., the certificate identified by the javax.net.ssl.keyStore properties.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message