Hello all,
Still hoping somebody can provide input on the question below.
Our software has both client and server connections, and will not request
clients to re-authenticate (HelloRequest), nor initiate re-authentication to
servers (ClientHello).
We like to disable re-authentication such
Hi,
Another question for TLS/TCP and DTLS/SCTP...
After initially successful authentication, is it possible to disable
re-authentication such that HelloRequest/ClientHello messages are ignored?
I've looked through the documentation, and tried to track down examples, but
have not
* Kyle Hamilton wrote on Thu, Apr 10, 2008 at 02:34 -0700:
> > (That means the CA remotely signs online submitted CSRs and sends
> > back a Cert immediately? Maybe such a CA would not be that
> > trustworthy...)
>
> First: it is as trustworthy as the application seems to
> require. It's not
On Thu, Apr 10, 2008 at 2:00 AM, Steffen DETTMER
<[EMAIL PROTECTED]> wrote:
> * Kyle Hamilton wrote on Wed, Apr 09, 2008 at 14:22 -0700:
> > Each peer goes through this process:
> > 1) peer creates a keypair
> > 2) peer generates a CSR (certificate signing request) for its public key.
> > 3) pe
On Wed, Nov 30, 2005 at 04:44:10PM +0100, Bernhard Froehlich wrote:
> As I see it it's more or less a matter of taste wether you implement
> such things using certificate extenstions or use the database approach.
> Some things to consider:
>
> - You can't modify certificate extensions, you'll h
Hi Bear,
> > Are there any additional steps necessary to verifying the issuer
> > apart from the normal peer authentication and a string compare of
> > the issuer name?
>
> Just follow the certificate chain back to a trusted root. Anyone
> can forge a certificate chain, but they won't be able t
Mark wrote:
Hi Bear,
As I said, just remember to use some intelligence. Verify the
issuer, be prepared for the case where a clueless CA issues the
same serial number (which is definitely an error, but how will you
handle it?), etc.
Are there any additional steps necess
Mark wrote:
> Are there any additional steps necessary to verifying the issuer
> apart from the normal peer authentication and a string compare of
> the issuer name?
Just follow the certificate chain back to a trusted root. Anyone
can forge a certificate chain, but they won't be able to get back
Hi Bear,
> As I said, just remember to use some intelligence. Verify the
> issuer, be prepared for the case where a clueless CA issues the
> same serial number (which is definitely an error, but how will you
> handle it?), etc.
Are there any additional steps necessary to verifying the issuer
apa
Mark wrote:
>>No hash can be guaranteed to be unique. Issuer and serial number
>>should be, but of course you need to exercise some intelligence here.
>
> In that case I'll use the Issuer and Serial number. Thanks.
As I said, just remember to use some intelligence. Verify the
issuer, be prepare
Hi Bear,
> > I noticed a function X509_subject_name_hash(). Will that
> give a unique
> > reference to a certificate? It seems to ;-)
>
> No hash can be guaranteed to be unique. Issuer and serial number
> should be, but of course you need to exercise some intelligence here.
>
> You can use
Mark wrote:
> I noticed a function X509_subject_name_hash(). Will that give a unique
> reference to a certificate? It seems to ;-)
No hash can be guaranteed to be unique. Issuer and serial number
should be, but of course you need to exercise some intelligence here.
You can use the subject hash
I've looked at that file but my understanding is still limited. There's
virtually no comments so it's hard to untangle what it is doing.
I noticed a function X509_subject_name_hash(). Will that give a unique
reference to a certificate? It seems to ;-)
There are several calls to a functi
Hi Peter,
> Read apps/x509.c how it parses the different ways to format a subject
> and issuer.
I've looked at that file but my understanding is still limited. There's
virtually no comments so it's hard to untangle what it is doing.
I noticed a function X509_subject_name_hash(). Will that giv
etc. ==> cf apps/x509.c
I must admit to being even more confused after the all the replies
to this thread! Thanks for all the input ;-)
I
Read apps/x509.c how it parses the different ways to format a subject
and issuer.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela
Hi All,
> The code below gives the FIRST Common Name RDN, not the last
> one in the hierarchy
> to be tested as a servername in tls. But well, if you only have one
> occurrence of common name :-)
>
> Anyway, the WHOLE DN, i.e. all attributes together are supposed to be
> unique in a CA.
> Of
On Wed, Nov 30, 2005 at 07:32:07PM +0100, Peter Sylvester wrote:
>
> C=FR;O=JANUS;CN="server1";CN=server2"
>
> What I mean with LAST is: The code gives server1, but what should be
> compared should be server2
>
AFAIK multiple CNs are not valid in the context of at least server
certificates.
C=FR;O=JANUS;CN="server1";CN=server2"
What I mean with LAST is: The code gives server1, but what should be
compared should be server2
Victor Duchovni wrote:
On Wed, Nov 30, 2005 at 06:40:38PM +0100, Peter Sylvester wrote:
The code below gives the FIRST Common Name RDN, not the last one
On Wed, Nov 30, 2005 at 06:40:38PM +0100, Peter Sylvester wrote:
> The code below gives the FIRST Common Name RDN, not the last one in the
> hierarchy to be tested as a servername in tls.
Yes, that is its purpose, verifying DNS names in server certificates.
There is more code (not shown) that fi
Peter Sylvester wrote:
> Bear Giles wrote:
>> The Common Name. You could use it as an LDAP key, convert it to a
>> string and use that a key into a database, etc.
>>
> You probably mean the Subject DN.
Yes. oops. I need to get better at proofreading. :)
_
The code below gives the FIRST Common Name RDN, not the last one in the
hierarchy
to be tested as a servername in tls. But well, if you only have one
occurrence of common name :-)
Anyway, the WHOLE DN, i.e. all attributes together are supposed to be
unique in a CA.
Of course, if your private
Bear Giles wrote:
Mark wrote:
What feature of a certificate could I use to provide an unique key
in a database table for this? How could this be extracted in a
program?
The Common Name. You could use it as an LDAP key, convert it to a
string and use that a key into a database, etc.
On Wed, Nov 30, 2005 at 04:28:04PM -, Mark wrote:
> Hi Bear,
>
> > Mark wrote:
> > > What feature of a certificate could I use to provide an unique key
> > > in a database table for this? How could this be extracted in a
> > > program?
> >
> > The Common Name. You could use it as an LDAP
Hi Bear,
> Mark wrote:
> > What feature of a certificate could I use to provide an unique key
> > in a database table for this? How could this be extracted in a
> > program?
>
> The Common Name. You could use it as an LDAP key, convert it to a
> string and use that a key into a database, etc.
Mark wrote:
> What feature of a certificate could I use to provide an unique key
> in a database table for this? How could this be extracted in a
> program?
The Common Name. You could use it as an LDAP key, convert it to a
string and use that a key into a database, etc.
One important nit -- you
Hi,
Thank you Bear and Ted for your responses.
> On the server side, why not maintain a database of clients and
> FQDNs or IP addresses? What you gain in flexibility should more
> than offset the increased complexity in the code.
This is one of the options I am considering and, indeed, it does
Mark wrote:
Hi All,
Thanks again to all here who helped me with my understanding of
Certificates.
It is likely that we would want to embed some additional data in
client certificates to further enhance security. For example we
may wish to include a (list of) IP address(es) that the client
can
Mark wrote:
> It is likely that we would want to embed some additional data in
> client certificates to further enhance security. For example we
> may wish to include a (list of) IP address(es) that the client
> can connect from and reject those not on the list. Alternatively
> we could create a
You
can generate certificate request in your server that need certificate, and
transfer it to you CA machine, and sign it. Then install the certificate into
your server.
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On
Behalf Of Z. S.GhandSent: Saturday,
On Wed, 10 May 2000 [EMAIL PROTECTED] wrote:
> Hullo!
> Just started using OpenSSL on a RH6.2 box. I configured, made, installed
> with the defaults, took the stock ssh.pam file and slapped it into
> /etc/pam.d/ssh however I could not authenticate. I'm using a DSA host key
This is not an OpenSS
I imagine that what we did on IIS could be scripted around s_client
(but I'm not volunteering to write it!) on any server.
HTH
Mike Murphy
> -Original Message-
> From: Rich Salz [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 23 maart 2000 5:15
> To: [EMAIL PROTECTED]
>
> My question is, how's a typical authentication delegation implemented
> using SSL? I can visualize a point-to-point authetication happening between
> the client and ServiceA. But, how can I control access to ServiceB's
> resources by ServiceA unless ServiceA is acting on behalf of a authoris
32 matches
Mail list logo
