Victor Duchovni wrote:
The usual interpretation seems to be not an alternative in the sense
of "one more of the same", but rather "one more and possibly better
*representation* of the same".
The subject name in the certificate is an X.500 DN. What Internet
applications that want to authenticate
Victor Duchovni wrote:
is rather muddy... Used by whom? For what? In addition? Instead? So
perhaps the HTTPS RFC elaborates the intent of a rather poorly worded
base RFC.
Agreed. Yes, rfc2818 elaborates the intent in rfc2459 (which
got obsoleted by rfc3280). However, in the IETF SIP WG, we
ar
On Fri, Apr 21, 2006 at 02:11:39PM -0500, Vijay K. Gurbani wrote:
> Victor Duchovni wrote:
> >The usual interpretation seems to be not an alternative in the sense
> >of "one more of the same", but rather "one more and possibly better
> >*representation* of the same".
> >
> >The subject name in the
Victor Duchovni wrote:
The RFC recommends that one leave out the subject DN, and add a critical
extension with altNames. This does not really explain how matching
should work when the subject DN is present. HTTPS is not necessarily
normative for STARTTLS with SMTP, but in the absence of other gui
On Fri, Apr 21, 2006 at 11:55:46AM -0700, Heikki Toivonen wrote:
> > On Fri, Apr 21, 2006 at 12:24:10PM -0400, Victor Duchovni wrote:
> >> in X.500 DNs as candidate DNS names is a transitional hack. When DNS
> >> names are present in the SubjectAlternativeName extension, these (with RFC
> >> bless
Victor Duchovni wrote:
The usual interpretation seems to be not an alternative in the sense
of "one more of the same", but rather "one more and possibly better
*representation* of the same".
The subject name in the certificate is an X.500 DN. What Internet
applications that want to authenticate
Victor Duchovni wrote:
> On Fri, Apr 21, 2006 at 12:24:10PM -0400, Victor Duchovni wrote:
>> in X.500 DNs as candidate DNS names is a transitional hack. When DNS
>> names are present in the SubjectAlternativeName extension, these (with RFC
>> blessing) are taken to represent *ALL* the valid DNS nam
On Fri, Apr 21, 2006 at 02:28:12PM -0400, Richard Salz wrote:
> > Here we go: RFC 2818 section 3.1:
>
> You rock.
Thanks. Much of the credit goes to Lutz, since his peer verification
code for Postfix is how I learned this particular wizardly lore.
--
Viktor.
___
> Here we go: RFC 2818 section 3.1:
You rock.
/r$
--
SOA Appliances
Application Integration Middleware
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
On Fri, Apr 21, 2006 at 12:24:10PM -0400, Victor Duchovni wrote:
> The subject name in the certificate is an X.500 DN. What Internet
> applications that want to authenticate a connection to a given host are
> trying to verify is a DNS name. The convention for overloading CommonName
> in X.500 DNs
On Fri, Apr 21, 2006 at 11:42:34AM -0400, Richard Salz wrote:
> > Wow a 512 bit key! Really unwise.
>
> Ture.
>
> > You did not mention the
> >
> > X509v3 Subject Alternative Name:
> > DNS:helpdesk.cis.uab.edu
> >
> > When this is present the CN is ignored.
>
>
> Really? T
Richard Salz wrote:
Wow a 512 bit key! Really unwise.
Ture.
It's already been replaced with a 2048 bit key. :-) I was just
grasping at straws last night trying to figure out what was wrong.
You did not mention the
X509v3 Subject Alternative Name:
DNS:helpdesk
> Wow a 512 bit key! Really unwise.
Ture.
> You did not mention the
>
> X509v3 Subject Alternative Name:
> DNS:helpdesk.cis.uab.edu
>
> When this is present the CN is ignored.
Really? That seems like a bug. There's a reason why it's called
subjectAlternativeName, and not
On Fri, Apr 21, 2006 at 09:16:51AM -0500, Fran Fabrizio wrote:
> >The other lesson here, is don't be skimpy in your error reports. If your
> >server were not reachable from the public Internet, nobody would have
> >been able to help you. The key evidence (the details of the certificate)
> >was nev
The other lesson here, is don't be skimpy in your error reports. If your
server were not reachable from the public Internet, nobody would have
been able to help you. The key evidence (the details of the certificate)
was never reported.
Part of being a newbie (as I am when it comes to signing
On Fri, Apr 21, 2006 at 09:00:17AM -0500, Fran Fabrizio wrote:
>
> Yes, I need to make a stronger permanent key. I've been playing with
> all the various settings trying to figure out what's wrong: this is
> about the 7th certificate I've made for this server. :-)
>
> The helpdesk.cis.uab.edu
Yes, I need to make a stronger permanent key. I've been playing with
all the various settings trying to figure out what's wrong: this is
about the 7th certificate I've made for this server. :-)
The helpdesk.cis.uab.edu is an alias for the CA server, not for this
email server. But you seem
On Fri, Apr 21, 2006 at 07:00:32AM -0500, Fran Fabrizio wrote:
> Here's the conf file I used when I generated the request:
>
> >[EMAIL PROTECTED] CisCA]# more EmailServer.cnf
> >[ req ]
> >prompt = no
> >distinguished_name = crier.cis.uab.edu
> >
> >[ crier.cis.uab.edu ]
>
PS - I know the conf file says crier.cis.uab.edu and below I wrote imap.
The imap was just for example purposes; the one and only machine name
is crier.cis.uab.edu.
(Sometimes simplifying for example purposes ends up complicating... :-)
Brad Hards wrote:
On Friday 21 April 2006 06:23 am,
Here's the conf file I used when I generated the request:
[EMAIL PROTECTED] CisCA]# more EmailServer.cnf
[ req ]
prompt = no
distinguished_name = crier.cis.uab.edu
[ crier.cis.uab.edu ]
commonName = crier.cis.uab.edu
stateOrProvinceName = Alabama
countryN
On Friday 21 April 2006 06:23 am, Fran Fabrizio wrote:
> "You have attempted to establish a connection to imap.cis.uab.edu.
> However, the security certificate presented belongs to imap.cis.uab.edu."
Is that exactly how it is written? If so, you might have signed the
certificate with a FQDN (end
What would be some possible causes of the following error message that I
am getting on our IMAP clients (Thunderbird 1.5 and Outlook 2003) when
they retrieve the SSL certificate from the IMAP server:
"You have attempted to establish a connection to imap.cis.uab.edu.
However, the security ce
22 matches
Mail list logo
