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] |
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 |
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] |
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] |
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] |
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] |
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] |
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] |
>
> 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] |
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] |
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] |
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. > 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] |
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] |
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] |
> 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] |
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? 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) |
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] |
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. 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 |
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] |
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] |
Free forum by Nabble | Edit this page |