Phantom Domain Name Mismatch?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Phantom Domain Name Mismatch?

Fran Fabrizio

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 certificate presented belongs to imap.cis.uab.edu."

The names match perfectly, yet it is still warning me.  Maybe I missed
something when I created the signing request and then signed it.  Here's
what I did:

On the IMAP server:
 openssl genrsa -out imap.key
 openssl req -new -nodes -key imap.key -out imap.csr

On our local CA:
  openssl ca -policy local_ca_policy -out imapcert.pem -infiles imap.csr

And put the resulting imapcert.pem back in the location where the IMAP
server is expecting to find the public certificate.

Any immediate possibilities come to mind?

--
Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham
http://www.cis.uab.edu/
205.934.0653

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

bradh (Bugzilla)
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 (ending with the "."), but you have asked to talk to
a relative name (no final dot). That won't match.

Brad

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Fran Fabrizio
Here's the conf file I used when I generated the request:

> [root@it CisCA]# more EmailServer.cnf
> [ req ]
> prompt                  = no
> distinguished_name      = crier.cis.uab.edu
>
> [ crier.cis.uab.edu ]
> commonName              = crier.cis.uab.edu
> stateOrProvinceName     = Alabama
> countryName             = US
> emailAddress            = [hidden email]
> organizationName        = UAB CIS
> organizationalUnitName  = UAB CIS IT

That looks ok, right?


Brad Hards wrote:
> 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 (ending with the "."), but you have asked to talk to
> a relative name (no final dot). That won't match.
>
> Brad
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Fran Fabrizio
In reply to this post by bradh (Bugzilla)

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, 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 (ending with the "."), but you have asked to talk to
> a relative name (no final dot). That won't match.
>
> Brad
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: FW: hey

jimmy-6
In reply to this post by bradh (Bugzilla)
eda ithu enthade????

Sanjay Vasudevan wrote:
> 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 (ending with the "."), but you have asked to talk to
> a relative name (no final dot). That won't match.
>
> Brad

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
In reply to this post by Fran Fabrizio
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:
>
> >[root@it CisCA]# more EmailServer.cnf
> >[ req ]
> >prompt                  = no
> >distinguished_name      = crier.cis.uab.edu
> >
> >[ crier.cis.uab.edu ]
> >commonName              = crier.cis.uab.edu
> >stateOrProvinceName     = Alabama
> >countryName             = US
> >emailAddress            = [hidden email]
> >organizationName        = UAB CIS
> >organizationalUnitName  = UAB CIS IT
>

Wow a 512 bit key! Really unwise. This can be easily brute forced.

You did not mention the

            X509v3 Subject Alternative Name:
                DNS:helpdesk.cis.uab.edu

When this is present the CN is ignored. The error unfortunately reports
the subject CN, but the real problem is the bogus Alternative Name, you
if this name is also required, list both this name and the desired CN
as Alternative DNS names.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 8 (0x8)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: CN=UAB CIS Certificate Authority, ST=Alabama, C=US/emailAddress=[hidden email], O=UAB CIS Certificate Authority
        Validity
            Not Before: Apr 20 19:45:49 2006 GMT
            Not After : Apr 19 19:45:49 2011 GMT
        Subject: CN=crier.cis.uab.edu, ST=Alabama, C=US/emailAddress=[hidden email], O=UAB, OU=CIS
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (512 bit)
                Modulus (512 bit):
                    00:bd:00:0e:84:38:3a:69:27:cc:6b:04:68:de:71:
                    5a:bd:28:60:8b:9d:ef:14:f5:4e:74:be:d5:f7:e0:
                    38:c9:2f:03:cf:2e:6d:80:bb:af:96:c7:be:4e:a8:
                    80:f0:aa:e9:db:3a:ae:11:6d:4e:33:a5:ff:9b:a0:
                    57:45:f6:a7:d3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:helpdesk.cis.uab.edu
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
    Signature Algorithm: md5WithRSAEncryption
        41:45:8c:df:7d:10:44:c1:47:86:40:20:1e:79:ae:c3:18:3f:
        7d:e9:f9:62:18:af:bd:7f:f3:98:4b:cf:e8:c5:26:1a:97:04:
        6e:d3:b7:f7:15:92:78:fd:31:90:95:27:71:ad:b4:0f:d6:92:
        24:ec:7f:43:60:39:f9:2a:d6:bf:9f:05:e2:35:a5:08:6a:8e:
        bb:38:40:1f:7c:fb:7c:92:39:68:41:4c:1b:62:90:b4:2e:b2:
        48:89:70:ef:56:a7:8a:d1:5c:98:e9:93:d4:f0:3d:28:27:67:
        02:5c:8e:eb:39:eb:40:0d:41:1c:a8:c7:55:22:3b:21:c6:91:
        02:e6:96:f6:8f:22:b1:c4:2d:85:e9:73:c9:41:0f:04:b2:be:
        08:a2:47:17:2e:61:95:10:76:07:8f:d1:19:ea:d3:82:63:1a:
        df:ce:93:c8:90:7f:75:27:ad:42:eb:0d:58:0a:4c:2f:13:21:
        7c:d6:7f:6e:cb:b0:59:e8:07:de:6e:05:b9:f1:62:c3:55:b5:
        28:88:b9:f3:21:0c:8e:56:f6:d2:e4:81:0f:57:75:02:e1:78:
        b2:e1:e2:af:60:8c:52:d7:5f:c6:b5:a5:b3:04:60:fb:e9:75:
        e3:18:26:b0:5a:da:3a:1c:fd:56:ff:bc:cb:f5:d4:f3:a6:40:
        f4:70:93:ca
-----BEGIN CERTIFICATE-----
MIIDATCCAemgAwIBAgIBCDANBgkqhkiG9w0BAQQFADCBkjEmMCQGA1UEAxMdVUFC
IENJUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEDAOBgNVBAgTB0FsYWJhbWExCzAJ
BgNVBAYTAlVTMSEwHwYJKoZIhvcNAQkBFhJzeXNhZG1AY2lzLnVhYi5lZHUxJjAk
BgNVBAoTHVVBQiBDSVMgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDQyMDE5
NDU0OVoXDTExMDQxOTE5NDU0OVowejEaMBgGA1UEAxMRY3JpZXIuY2lzLnVhYi5l
ZHUxEDAOBgNVBAgTB0FsYWJhbWExCzAJBgNVBAYTAlVTMSEwHwYJKoZIhvcNAQkB
FhJzeXNhZG1AY2lzLnVhYi5lZHUxDDAKBgNVBAoTA1VBQjEMMAoGA1UECxMDQ0lT
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL0ADoQ4OmknzGsEaN5xWr0oYIud7xT1
TnS+1ffgOMkvA88ubYC7r5bHvk6ogPCq6ds6rhFtTjOl/5ugV0X2p9MCAwEAAaNB
MD8wHwYDVR0RBBgwFoIUaGVscGRlc2suY2lzLnVhYi5lZHUwCQYDVR0TBAIwADAR
BglghkgBhvhCAQEEBAMCBkAwDQYJKoZIhvcNAQEEBQADggEBAEFFjN99EETBR4ZA
IB55rsMYP33p+WIYr71/85hLz+jFJhqXBG7Tt/cVknj9MZCVJ3GttA/WkiTsf0Ng
Ofkq1r+fBeI1pQhqjrs4QB98+3ySOWhBTBtikLQuskiJcO9Wp4rRXJjpk9TwPSgn
ZwJcjus560ANQRyox1UiOyHGkQLmlvaPIrHELYXpc8lBDwSyvgiiRxcuYZUQdgeP
0Rnq04JjGt/Ok8iQf3UnrULrDVgKTC8TIXzWf27LsFnoB95uBbnxYsNVtSiIufMh
DI5W9tLkgQ9XdQLheLLh4q9gjFLXX8a1pbMEYPvpdeMYJrBa2joc/Vb/vMv11POm
QPRwk8o=
-----END CERTIFICATE-----

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Fran Fabrizio

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 to have spotted that I have that set wrong
somewhere!  And now that I think about it, I don't think I need to
specify the alternative names for the CA anywhere.

That error message would be great if it pointed out the real problem,
but I should've spotted that.

Thanks!




Victor Duchovni wrote:

> 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:
>>
>>    
>>> [root@it CisCA]# more EmailServer.cnf
>>> [ req ]
>>> prompt                  = no
>>> distinguished_name      = crier.cis.uab.edu
>>>
>>> [ crier.cis.uab.edu ]
>>> commonName              = crier.cis.uab.edu
>>> stateOrProvinceName     = Alabama
>>> countryName             = US
>>> emailAddress            = [hidden email]
>>> organizationName        = UAB CIS
>>> organizationalUnitName  = UAB CIS IT
>>>      
>
> Wow a 512 bit key! Really unwise. This can be easily brute forced.
>
> You did not mention the
>
>             X509v3 Subject Alternative Name:
> DNS:helpdesk.cis.uab.edu
>
> When this is present the CN is ignored. The error unfortunately reports
> the subject CN, but the real problem is the bogus Alternative Name, you
> if this name is also required, list both this name and the desired CN
> as Alternative DNS names.
>
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 8 (0x8)
>         Signature Algorithm: md5WithRSAEncryption
>         Issuer: CN=UAB CIS Certificate Authority, ST=Alabama, C=US/emailAddress=[hidden email], O=UAB CIS Certificate Authority
>         Validity
>             Not Before: Apr 20 19:45:49 2006 GMT
>             Not After : Apr 19 19:45:49 2011 GMT
>         Subject: CN=crier.cis.uab.edu, ST=Alabama, C=US/emailAddress=[hidden email], O=UAB, OU=CIS
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>             RSA Public Key: (512 bit)
>                 Modulus (512 bit):
>                     00:bd:00:0e:84:38:3a:69:27:cc:6b:04:68:de:71:
>                     5a:bd:28:60:8b:9d:ef:14:f5:4e:74:be:d5:f7:e0:
>                     38:c9:2f:03:cf:2e:6d:80:bb:af:96:c7:be:4e:a8:
>                     80:f0:aa:e9:db:3a:ae:11:6d:4e:33:a5:ff:9b:a0:
>                     57:45:f6:a7:d3
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             X509v3 Subject Alternative Name:
>                 DNS:helpdesk.cis.uab.edu
>             X509v3 Basic Constraints:
>                 CA:FALSE
>             Netscape Cert Type:
>                 SSL Server
>     Signature Algorithm: md5WithRSAEncryption
>         41:45:8c:df:7d:10:44:c1:47:86:40:20:1e:79:ae:c3:18:3f:
>         7d:e9:f9:62:18:af:bd:7f:f3:98:4b:cf:e8:c5:26:1a:97:04:
>         6e:d3:b7:f7:15:92:78:fd:31:90:95:27:71:ad:b4:0f:d6:92:
>         24:ec:7f:43:60:39:f9:2a:d6:bf:9f:05:e2:35:a5:08:6a:8e:
>         bb:38:40:1f:7c:fb:7c:92:39:68:41:4c:1b:62:90:b4:2e:b2:
>         48:89:70:ef:56:a7:8a:d1:5c:98:e9:93:d4:f0:3d:28:27:67:
>         02:5c:8e:eb:39:eb:40:0d:41:1c:a8:c7:55:22:3b:21:c6:91:
>         02:e6:96:f6:8f:22:b1:c4:2d:85:e9:73:c9:41:0f:04:b2:be:
>         08:a2:47:17:2e:61:95:10:76:07:8f:d1:19:ea:d3:82:63:1a:
>         df:ce:93:c8:90:7f:75:27:ad:42:eb:0d:58:0a:4c:2f:13:21:
>         7c:d6:7f:6e:cb:b0:59:e8:07:de:6e:05:b9:f1:62:c3:55:b5:
>         28:88:b9:f3:21:0c:8e:56:f6:d2:e4:81:0f:57:75:02:e1:78:
>         b2:e1:e2:af:60:8c:52:d7:5f:c6:b5:a5:b3:04:60:fb:e9:75:
>         e3:18:26:b0:5a:da:3a:1c:fd:56:ff:bc:cb:f5:d4:f3:a6:40:
>         f4:70:93:ca
> -----BEGIN CERTIFICATE-----
> MIIDATCCAemgAwIBAgIBCDANBgkqhkiG9w0BAQQFADCBkjEmMCQGA1UEAxMdVUFC
> IENJUyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxEDAOBgNVBAgTB0FsYWJhbWExCzAJ
> BgNVBAYTAlVTMSEwHwYJKoZIhvcNAQkBFhJzeXNhZG1AY2lzLnVhYi5lZHUxJjAk
> BgNVBAoTHVVBQiBDSVMgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDQyMDE5
> NDU0OVoXDTExMDQxOTE5NDU0OVowejEaMBgGA1UEAxMRY3JpZXIuY2lzLnVhYi5l
> ZHUxEDAOBgNVBAgTB0FsYWJhbWExCzAJBgNVBAYTAlVTMSEwHwYJKoZIhvcNAQkB
> FhJzeXNhZG1AY2lzLnVhYi5lZHUxDDAKBgNVBAoTA1VBQjEMMAoGA1UECxMDQ0lT
> MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL0ADoQ4OmknzGsEaN5xWr0oYIud7xT1
> TnS+1ffgOMkvA88ubYC7r5bHvk6ogPCq6ds6rhFtTjOl/5ugV0X2p9MCAwEAAaNB
> MD8wHwYDVR0RBBgwFoIUaGVscGRlc2suY2lzLnVhYi5lZHUwCQYDVR0TBAIwADAR
> BglghkgBhvhCAQEEBAMCBkAwDQYJKoZIhvcNAQEEBQADggEBAEFFjN99EETBR4ZA
> IB55rsMYP33p+WIYr71/85hLz+jFJhqXBG7Tt/cVknj9MZCVJ3GttA/WkiTsf0Ng
> Ofkq1r+fBeI1pQhqjrs4QB98+3ySOWhBTBtikLQuskiJcO9Wp4rRXJjpk9TwPSgn
> ZwJcjus560ANQRyox1UiOyHGkQLmlvaPIrHELYXpc8lBDwSyvgiiRxcuYZUQdgeP
> 0Rnq04JjGt/Ok8iQf3UnrULrDVgKTC8TIXzWf27LsFnoB95uBbnxYsNVtSiIufMh
> DI5W9tLkgQ9XdQLheLLh4q9gjFLXX8a1pbMEYPvpdeMYJrBa2joc/Vb/vMv11POm
> QPRwk8o=
> -----END CERTIFICATE-----
>
>  


--
Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham
http://www.cis.uab.edu/
205.934.0653

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
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 is an alias for the CA server, not for this
> email server.  But you seem to have spotted that I have that set wrong
> somewhere!  And now that I think about it, I don't think I need to
> specify the alternative names for the CA anywhere.
>
> That error message would be great if it pointed out the real problem,
> but I should've spotted that.

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.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Fran Fabrizio
>
> 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 certificates)
is learning what the important pieces of information are when asking for
help.   Now I know.  :-)   Thanks again.



--
Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham
http://www.cis.uab.edu/
205.934.0653

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
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 never reported.
> >  
>
> Part of being a newbie (as I am when it comes to signing certificates)
> is learning what the important pieces of information are when asking for
> help.   Now I know.  :-)   Thanks again.

Yes, those who know exactly what to include in a problem report, already
know the solution. The key skill for a newbie is to include every bit of
available information, and not let your assumptions of what is relevant
filter the data you provide.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Richard Salz
In reply to this post by Victor Duchovni
> 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 subjectPreferredName. Nevertheless, as you
say, putting both names is a reasonable work-around.

        /r$

--
SOA Appliances
Application Integration Middleware


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Fran Fabrizio
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.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 subjectPreferredName. Nevertheless, as you
> say, putting both names is a reasonable work-around.
>  
That also explains another weird behavior I was seeing, so it is good to
know about this.

--
Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham
http://www.cis.uab.edu/
205.934.0653

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
In reply to this post by Richard Salz
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?  That seems like a bug.  There's a reason why it's called
> subjectAlternativeName, and not subjectPreferredName. Nevertheless, as you
> say, putting both names is a reasonable work-around.
>

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 a connection to a given host are
trying to verify is a DNS name. The convention for overloading CommonName
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 names of the subject.

I don't have an RFC reference for such an interpretation. Anyone have
a handy reference?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
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 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 names of the subject.
>
> I don't have an RFC reference for such an interpretation. Anyone have
> a handy reference?

Here we go: RFC 2818 section 3.1:

    If a subjectAltName extension of type dNSName is present, that MUST
    be used as the identity. Otherwise, the (most specific) Common Name
    field in the Subject field of the certificate MUST be used. Although
    the use of the Common Name is existing practice, it is deprecated and
    Certification Authorities are encouraged to use the dNSName instead.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Richard Salz
> 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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Vijay K. Gurbani
In reply to this post by Victor Duchovni
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 a connection to a given host are
> trying to verify is a DNS name. The convention for overloading CommonName
> 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 names of the subject.
>
> I don't have an RFC reference for such an interpretation. Anyone have
> a handy reference?
RFC 3280, Section 4.2.1.7.

Thanks,

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

smime.p7s (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
In reply to this post by Richard Salz
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.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Heikki Toivonen
In reply to this post by Victor Duchovni
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 names of the subject.
>
> Here we go: RFC 2818 section 3.1:
>
>     If a subjectAltName extension of type dNSName is present, that MUST
>     be used as the identity. Otherwise, the (most specific) Common Name
>     field in the Subject field of the certificate MUST be used. Although
>     the use of the Common Name is existing practice, it is deprecated and
>     Certification Authorities are encouraged to use the dNSName instead.
I don't think the RFC wording is totally clear, although I lean on your
interpretation a little bit.

I have based my code on "Network Security with OpenSSL" book samples,
which first check dNSName but happily continue to check commonName if no
match was found in dNSName. Perhaps an errata to the book would be in
order? See page 136 (June 2002 First Edition).

--
  Heikki Toivonen



signature.asc (259 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Vijay K. Gurbani
In reply to this post by Victor Duchovni
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 a connection to a given host are
> trying to verify is a DNS name. The convention for overloading CommonName
> 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 names of the subject.
>
> I don't have an RFC reference for such an interpretation. Anyone have
> a handy reference?

RFC 3280, Section 4.2.1.7.

Thanks,

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Phantom Domain Name Mismatch?

Victor Duchovni
In reply to this post by Heikki Toivonen
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
> >> blessing) are taken to represent *ALL* the valid DNS names of the subject.
> >
> > Here we go: RFC 2818 section 3.1:
> >
> >     If a subjectAltName extension of type dNSName is present, that MUST
> >     be used as the identity. Otherwise, the (most specific) Common Name
> >     field in the Subject field of the certificate MUST be used. Although
> >     the use of the Common Name is existing practice, it is deprecated and
> >     Certification Authorities are encouraged to use the dNSName instead.
>
> I don't think the RFC wording is totally clear, although I lean on your
> interpretation a little bit.
>
> I have based my code on "Network Security with OpenSSL" book samples,
> which first check dNSName but happily continue to check commonName if no
> match was found in dNSName. Perhaps an errata to the book would be in
> order? See page 136 (June 2002 First Edition).

Sadly edge-case behaviour in X.509 peername verification is far from
uniform.  The most common case: single US-ASCII CN and no alternative
names is handled reasonably consistently by all implementations. More
exotic certificates are likely to trigger implementation specific
behaviour:

    - Failure to convert multi-byte encoded CNs to UTF-8 before
      matching.

      Many existing implementations just use the raw ASN.1 string data.

    - Disagreement about which of multiple CN values in the subject
      DN is applicable (first, last, most specific, what does "most
      specific" mean anyway?).

      Many implementations just use the first CN. Even though this
      may not be strictly correct, Postfix is staying with "use first"
      approach, because there are no reports of problems, and we don't
      know whether changing this will break valid certs.

    - Disagreement about the semantics of the DN in the presence of
      subjectAltNames. Use both if present, or just the altNames?

There may be other ways to mess up. Both books and time-tested
implementations sometimes get the subtle details wrong. Still, I think the
(HTTPS) RFC is rather clear. The X.509 Internet profile RFCs are as far as
I can tell silent on the last issue.

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 guidance,
the HTTPS recommendations have been adopted in other application areas.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
12