A new false issued certificate by Comdo?
Paul van Brouwershaven
Yesterday I found a new false issued certificate for defence.external.int. It looks like the
problems with Comodo are still not solved. Isn't it?
The certificate below has been issued by Comodo just a few days ago on the domain external.int which
hasn't been registered.
I'm surprised that this bug is still listed as "new" after it has been open for almost a year.
Comodo apparently not solved the problem.
They are still seen as a trusted certificate authority. But how many false issued certificate would
there be on the Comodo roots? Or is this the only one? I don't think so.
>>>>>>>>>>>>>>>>>>>> THE CERTIFICATE <<<<<<<<<<<<<<<<<<<<
-----BEGIN CERTIFICATE-----
MIIFAzCCA+ugAwIBAgIQNDAhbYnYDq1arx2R5g5oWzANBgkqhkiG9w0BAQUFADB7
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE
AxMYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTA5MTAyOTAwMDAwMFoXDTEw
MTAyOTIzNTk1OVowgcQxCzAJBgNVBAYTAk5MMRAwDgYDVQQREwcyNTE2IEFCMRUw
EwYDVQQIEwxadWlkLUhvbGxhbmQxEjAQBgNVBAcTCVRoZSBIYWd1ZTEVMBMGA1UE
CRMMTWFhbndlZywgMTc0MRAwDgYDVQQKEwdJQ0MtQ1BJMQ0wCwYDVQQLEwRJQ1RT
MSEwHwYDVQQLExhDb21vZG8gUHJlbWl1bVNTTCBMZWdhY3kxHTAbBgNVBAMTFGRl
ZmVuY2UuZXh0ZXJuYWwuaW50MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/
OOGdLQkom++eMFElFnpHt6kJ5IXKYq0+xVMU2IzVtiFE9sbnJgDNVnmMAQckbWyR
y9gd+6fmQDgruYWeCvGJKPOSv2VqqE74EaT2oBpgTEg/g3e3lpbVv8rWCuEx56bH
Cq9oLeKnmnpIr9pEVIBHITEMOIhARd8Z2LHXYTFU2wIDAQABo4IBuzCCAbcwHwYD
VR0jBBgwFoAUMEPcZM0ZXKnzGdI3CZaRngzo1j0wHQYDVR0OBBYEFItAyyoypBx2
5NiOQBkpJUZYt+cyMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEB
AgEDBDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ
UzB/BgNVHR8EeDB2MDqgOKA2hjRodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BQUFD
ZXJ0aWZpY2F0ZVNlcnZpY2VzXzIuY3JsMDigNqA0hjJodHRwOi8vY3JsLmNvbW9k
by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlc18yLmNybDA0BggrBgEFBQcBAQQo
MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTA5BgNVHREE
MjAwghRkZWZlbmNlLmV4dGVybmFsLmludIIYd3d3LmRlZmVuY2UuZXh0ZXJuYWwu
aW50MA0GCSqGSIb3DQEBBQUAA4IBAQAh2751OyeeorzVSe2dDadctYdNNnyEuYKp
8BFRdqjw2/R12zSNHDYaz13ETgFUFqimrdeRcDGgKyy6NC9q/QXmqxbYxnia1SoU
87TzxaK4zW7RlDwfMH2CtUmiSFuB5FAEEjaBsPBF/DrxH7yr8o+Cgb6TRSF8i+SV
MDEBB/DSNeXggLVoBGSAM/qiDTTw0nRcgNX8MUNspMSyaVxjl2wjLKk4yJY9G6kE
R2tzNFfwrrzOrAG9UMNwgqt6MsOEUIf+gSnInawG1DnZbD5gzD9xwU4rIDYs/Lw8
5hh7Ybse5li/RckCC1mAVWk56g9LNLRDoMFOtBwuPfU656nudg94
-----END CERTIFICATE-----
>>>>>>>>>>>>>>>>>>>> WHOIS <<<<<<<<<<<<<<<<<<<<
Registry: whois.iana.org
Results:
Domain external.int not found.
This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.
>>>>>>>>>>>>>>>>>>>> CRL <<<<<<<<<<<<<<<<<<<<
The crl at:
http://crl.comodoca.com/AAACertificateServices_2.crl
has no entry of this certificate with serial number:
3430216D89D80EAD5AAF1D91E60E685B
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
Last Update: Nov 3 01:51:21 2009 GMT
Next Update: Nov 7 01:51:21 2009 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:30:43:DC:64:CD:19:5C:A9:F3:19:D2:37:09:96:91:9E:0C:E8:D6:3D
X509v3 CRL Number:
1139
--
With kind regards,
Paul van Brouwershaven
Networking4all B.V.
____________________________________________
Phone: (31) 20 7881030 Fax: (31) 20 7881040
Email: p.vanbrou...@networking4all.com
Internet: http://www.networking4all.com
Florian Weimer
> Yesterday I found a new false issued certificate for
> defence.external.int. It looks like the problems with Comodo are
> still not solved. Isn't it?
Why do you think the certificate is bogus?
> The certificate below has been issued by Comodo just a few days ago
> on the domain external.int which hasn't been registered.
If there is ownership information in their Idauthority database, it is
possible to issue such a certificate in compliance with the CPS.
By the way, how did you obtain a copy of the certificate?
Reed Loden
Florian Weimer <f...@deneb.enyo.de> wrote:
> * Paul van Brouwershaven:
>
> > Yesterday I found a new false issued certificate for
> > defence.external.int. It looks like the problems with Comodo are
> > still not solved. Isn't it?
>
> Why do you think the certificate is bogus?
$ whois -h whois.iana.org external.int
Domain external.int not found.
This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.
SSL certificates shouldn't be issued to domains that don't exist. ;)
~reed
--
Reed Loden - <re...@reedloden.com>
Florian Weimer
Does the CPS really say that? Where?
Eddy Nigg
Why do you think the certificate is bogus?$ whois -h whois.iana.org external.int Domain external.int not found. This whois server only provides data for which IANA is authoritative, including ".int" domains, ".arpa" domains, top level domains, and some reserved names. SSL certificates shouldn't be issued to domains that don't exist. ;)
Anyway.... to the subject, external.int doesn't appear to be a valid domain name, nor does it appear to have been valid at the time of issuance, hence this certificates was not validated properly.
Additionally .int is a valid TLD managed by IANA directly.
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
Does the CPS really say that? Where?
for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
Here is the link to the policy: http://www.mozilla.org/projects/security/certs/policy/
Paul van Brouwershaven
> By the way, how did you obtain a copy of the certificate?
limited browser compatibility. (read supprot for mobile devices etc)
No other CA could deliver this certificate because the domain has not been registererd. My client
forwarded the certificate to prove he really got this certificate from Comodo.
Ian G
OK, so it's good to figure out all the facts before we jump to conclusions.
Why does the client want this certificate? What is the use case here?
Does the domain exist "for him" and we just can't see it (I'm thinking
some internal non-public internet sense here) ?
Or is this an "embarrassment exercise" ?
iang
Paul van Brouwershaven
> OK, so it's good to figure out all the facts before we jump to conclusions.
> Why does the client want this certificate? What is the use case here?
This client uses .int for an internal domain, but this does not changes the case. The certificate
should not be issued because the domain has not been registered and could still be registered by
some else.
> Does the domain exist "for him" and we just can't see it (I'm thinking
> some internal non-public internet sense here) ?
It's used on a intranet, but this will not say this is a valid certificate. You can't validate
domain ownership if a domain has not been registered!
> Or is this an "embarrassment exercise" ?
Believe me it's not!
Dave Miller
<eddy...@startcom.org> wrote:
> I'm again not seeing the original posting, why doesn't it come through?
> I see only your replies. Something with the mail <-> news gateway is
> broken :S
Giganews says the original message got nailed as a binary post because
of the included base64-encoded SSL certificate.
It's available on Google:
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread
/cf549767028f79c0#
--
Dave Miller
Systems Administrator, Mozilla Corporation
Eddy Nigg
>
> Giganews says the original message got nailed as a binary post because
> of the included base64-encoded SSL certificate.
>
Specially on these news groups this can happen from time to time. Is
this something which can be fixed?
Collin Jackson
internal domains, including Comodo, VeriSign, and completessl.com.
Adam Barth and I filed a bug on this issue in 2007. These
certificates are easy to acquire, but I don't see how they're less
secure than HTTP, so we've been advocating that browsers show
a broken lock:
https://bugzilla.mozilla.org/show_bug.cgi?id=401317
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Paul van Brouwershaven
> I've found several certificate authorities that issue certificates for
> internal domains, including Comodo, VeriSign, and completessl.com.
> Adam Barth and I filed a bug on this issue in 2007. These
> certificates are easy to acquire, but I don't see how they're less
> secure than HTTP, so we've been advocating that browsers show
> a broken lock:
http://www.iana.org/domains/root/db/int.html
Eddy Nigg
I've found several certificate authorities that issue certificates for internal domains, including Comodo, VeriSign, and completessl.com. Adam Barth and I filed a bug on this issue in 2007. These certificates are easy to acquire, but I don't see how they're less secure than HTTP, so we've been advocating that browsers show a broken lock:
https://bugzilla.mozilla.org/show_bug.cgi?id=401317
Hi Collin,
The point with this certificate is, that this is a real, valid TLD.
Second, the problematic practices already has this listed: https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses
This item has been also taken to the CAB Forum and is discussed and hopefully included with the Basic SSL Guidelines which are in the making. Host-names and internal IP addresses provide NO PROTECTION whatsoever and is pure snake oil. CAs which issue such certificates deceive their customers and relying parties.
In this particular issue, the above doesn't apply since this was issued to a non-existing domain name of a real TLD.
Collin Jackson
If you register a certificate with a "." in it, Comodo's instantssl.com
store usually sends a domain validation email (to
ad...@external.int, admini...@external.int, etc.). In this case,
I would think the email would never arrive, right?
On Wed, Nov 4, 2009 at 9:35 PM, Paul van Brouwershaven
<p.vanbrou...@networking4all.com> wrote:
> Collin Jackson schreef:
>> I've found several certificate authorities that issue certificates for
>> internal domains, including Comodo, VeriSign, and completessl.com.
>> Adam Barth and I filed a bug on this issue in 2007. These
>> certificates are easy to acquire, but I don't see how they're less
>> secure than HTTP, so we've been advocating that browsers show
>> a broken lock:
Dave Miller
<eddy...@startcom.org> wrote:
> On 11/04/2009 11:13 PM, Dave Miller:
> >
> > Giganews says the original message got nailed as a binary post because
> > of the included base64-encoded SSL certificate.
> >
>
> Specially on these news groups this can happen from time to time. Is
> this something which can be fixed?
Not unless we host it all ourselves (which has been discussed, and will
probably happen someday, but not anytime soon probably.
Ben Bucksch
> * Reed Loden:
>>
> Does the CPS really say that? Where?
>
SSL certs should be issued only to the owner of the domain or party in
control of the domain. (The requirements are explicit about that.)
Given that non-existing domains don't have an owner, there must not be
certs issued for them.
Ben
Ian G
But creating domains is a matter of editing /etc/hosts and DNS and so
forth. The problem is a little more nuanced than whether it exists or not.
The questions seems to be
(a) whether the owner of the TLD .int in the public internet also
owns/controls by some means all of the uses of the .int domains in
internal non-public facing nets (e.g., has rights over my /etc/hosts
file), and
(b) whether there is an ability for any domain to exist inside a
corporate network and to be served a cert signed by a CA's root where
the root is also serving public-facing FQDNs.
I'm not sure what the answers are.
for (a): If I have a corporate network and for some reason I'm
using ".int" for all my internal domains ... I don't see that some big
internet TLD can take that away from me. What happens if I switch all
my internal domains to say '.loc' and next year the ICANN decides to
award the .loc TLD ... arrghhhh... Or say, I'm a computer company using
.apple and the Apple record company successfully purchases the .apple
TLD. Oh no, back to intellectual property court we go...
for (b): If I have a million-node internal network across the world
(like the USG is allegedly building) and I want to run SSL within ...
then I might want to use standard CA-signed roots because I don't
necessarily want to provision a new root into every browser (some
browsers have trouble with mass provisioning).
Where it gets sticky is if a corporate gets a domain/cert that also
clashes with a public one. (That's not the case here.)
But even then, there is still not necessarily going to be a ban, as we
accept the approximate possibility of domain/cert clashes in other
respects (IDNs, different TLDs, and other "phishing" possibilities).
And there could be a business case for this, such as some provider
deciding to set up a test network with all its customer websites internally.
Where we would typically solve this with a *business approach* is to set
a contract condition. Unfortunately, we don't evaluate the strength of
contracts in this place, that is left somewhat to the auditor (depending
on the strength of the audit criteria it seems). If we did, it would be
a simple matter of saying "where internal non-visible domains are
certified, adequate care and contract provisions are taken to ensure the
public net is not at risk."
Possibly this could go back to IANA and RFC-land for them to invent a
guaranteed non-public TLD? Like example.com but backwards, like
10.0.0.1 but in words.
just some thoughts... it's one of those areas where leaping to
conclusions, especially from a biased point of view is likely to cause
problems.
iang
Reed Loden
Ian G <ia...@iang.org> wrote:
> Possibly this could go back to IANA and RFC-land for them to invent a
> guaranteed non-public TLD? Like example.com but backwards, like
> 10.0.0.1 but in words.
RFC 2606 specifies four reserved TLDs for testing/documentation:
* .test
* .example
* .invalid
* .localhost
Also, Microsoft, Apple, and Ubuntu all either recommend or have
products that use the .local TLD for such internal network purposes.
This TLD is not RFC-official, but it seems to be the collective
default for such uses. Now, if somebody wants to petition IANA to
make .test an actual reserved TLD for purposes such as this, that would
probably be a very good thing. :)
Reed Loden
Reed Loden <re...@reedloden.com> wrote:
> Now, if somebody wants to petition IANA to make .test an actual
> reserved TLD for purposes such as this, that would probably be a very
> good thing. :)
... and by .test, I really mean .local. Sorry for the typo.
Ian G
> On Thu, 05 Nov 2009 04:04:09 +0100
> Ian G<ia...@iang.org> wrote:
>
>> Possibly this could go back to IANA and RFC-land for them to invent a
>> guaranteed non-public TLD? Like example.com but backwards, like
>> 10.0.0.1 but in words.
>
> RFC 2606 specifies four reserved TLDs for testing/documentation:
> * .test
> * .example
> * .invalid
> * .localhost
Thanks for that!
> Also, Microsoft, Apple, and Ubuntu all either recommend or have
> products that use the .local TLD for such internal network purposes.
> This TLD is not RFC-official, but it seems to be the collective
> default for such uses. Now, if somebody wants to petition IANA to
> make .local an actual reserved TLD for purposes such as this, that would
> probably be a very good thing. :)
OK, so back to Paul and his friend: Is there a good reason / a viable
business case for why the customer is not using one of the above 5 options?
iang
Paul van Brouwershaven
> Do you know what web site the client used to register it originally?
certificated. (something like OU=Provided by [partner x]) So it looks it bought from one of the
Comodo sites itself.
> If you register a certificate with a "." in it, Comodo's instantssl.com
> store usually sends a domain validation email (to
> ad...@external.int, admini...@external.int, etc.). In this case,
> I would think the email would never arrive, right?
The mail will never arrive, but this is no domain validated certificate but an OV certificate.
Subject: C=NL/postalCode=2516 AB, ST=Zuid-Holland, L=The Hague/streetAddress=Maanweg, 174,
O=ICC-CPI, OU=ICTS, OU=Comodo PremiumSSL Legacy, CN=defence.external.int
Paul van Brouwershaven
> OK, so back to Paul and his friend: Is there a good reason / a viable
> business case for why the customer is not using one of the above 5 options?
They probably never checked if there is a special internal TLD and thought this was a non existing
TLD or that they simply used the domain because it has never been registered.
Ben Bucksch
>> SSL certs should be issued only to the owner of the domain or party in
>> control of the domain. (The requirements are explicit about that.)
>> Given that non-existing domains don't have an owner, there must not be
>> certs issued for them.
>
>
>
> But creating domains is a matter of editing /etc/hosts and DNS and so
> forth.
No, /etc/hosts doesn't count, only the public Internet DNS namespace
managed by IANA/ICANN. Otherwise I would be, by the same logic, the
"owner" of download.microsoft.com as soon as I create such an entry in
my personal /etc/hosts. That's utter nonsense. Same goes for
external.net or external.int.
> for (a): If I have a corporate network and for some reason I'm
> using ".int" for all my internal domains
... then that hypothetical you better get a clue. ".int" doesn't mean
"internal", but "international", and is an official, real, assigned TLD.
If you need a domain for yourself, including SSL, then register it.
Costs $12/year.
I don't think "ex.example.com" or "int.example.net" is that much harder
to remember or type than "external.int" either. And you can get an SSL
cert for it. And you won't get problems when you connect networks with
partners.
> Where we would typically solve this with a *business approach* is to
> set a contract condition.
No, that would still be a violation of our policy. It governs all certs
issued under a certain root. Otherwise it would be meaningless.
Florian Weimer
> This item has been also taken to the CAB Forum and is discussed and
> hopefully included with the Basic SSL Guidelines which are in the
> making. Host-names and internal IP addresses provide *NO PROTECTION*
> whatsoever and is pure snake oil. CAs which issue such certificates
> deceive their customers and relying parties.
Sorry, this is just not true. The suppression of the browser warning
is a value for which people pay. Without the certificate, the browser
warning would reduce end user confidence in the service, essentially
reducing security as perceived by the end user.
(The system doesn't do much else anyway, but at least this type of
service is provided by CAs.)
Paul van Brouwershaven
webmail.chess.nl (chess.nl on: nl) - chess - NL
DNS:webmail.chess.nl,DNS:exalg01.chess.int,DNS:webmail.exchange.chess-it.com
webmail.chess.nl
exalg01.chess.int [dns error]
webmail.exchange.chess-it.com [other domain]
Serial: B3EA62E9256A4317FB3C28DF90007978
Not in crl version 1141 from Nov 5 02:04:18 2009 GMT
>>>>>>>>>>>>>>>>>>>> WHOIS <<<<<<<<<<<<<<<<<<<<
Registry: whois.iana.org
Results:
Domain chess.int not found.
This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.
>>>>>>>>>>>>>>>>>>>> THE CERTIFICATE <<<<<<<<<<<<<<<<<<<<
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b3:ea:62:e9:25:6a:43:17:fb:3c:28:df:90:00:79:78
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
Validity
Not Before: Jun 24 00:00:00 2008 GMT
Not After : Jun 24 23:59:59 2011 GMT
Subject: C=NL/postalCode=2011 NJ, ST=Noord-Holland, L=Haarlem/streetAddress=Nieuwe Gracht
78/2.5.4.18=5021, 2900CA, Haarlem, O=chess, OU=Chess Beheer, OU=Comodo Unified Communications,
CN=webmail.chess.nl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c7:85:13:23:70:31:c6:45:53:d0:45:cb:9e:4a:
d6:92:0f:a9:07:c1:6c:17:c7:5c:45:b3:31:ac:3d:
69:d3:1a:97:9c:33:ee:96:a7:34:ca:74:94:f1:dc:
ec:fb:59:aa:8b:0b:a2:8d:c0:93:28:64:db:8f:d2:
07:9e:a4:d5:7e:63:76:3e:a4:55:78:cb:8c:7e:be:
9d:2a:94:2d:8b:32:05:aa:88:b3:a3:f3:c9:41:e9:
41:68:53:60:cd:78:fe:bd:d9:82:59:0c:7f:90:8f:
e0:00:5f:eb:9d:db:2d:b3:8b:7a:cc:45:4b:ba:16:
4d:85:9a:e0:42:cf:70:27:5f:fd:81:5e:aa:9f:ea:
3e:48:8b:22:60:e7:83:88:d7:7e:2d:ad:6d:3d:00:
c8:ed:11:c9:2e:69:aa:cf:50:03:b9:99:b4:65:dc:
b0:74:37:61:26:7e:74:09:03:26:ae:a4:a0:e3:b0:
0a:2c:ac:98:23:dd:17:ab:04:69:b0:a4:11:42:04:
7e:7d:00:33:65:ec:6f:34:23:68:b1:a8:9a:96:af:
2c:55:2b:1f:17:f8:2a:02:20:c7:bc:87:70:62:49:
cf:90:3a:75:17:8d:31:69:c0:61:a2:b3:bb:3f:4e:
aa:2d:63:9c:23:a5:40:77:0b:f0:5b:cb:9e:1d:13:
f0:97
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:30:43:DC:64:CD:19:5C:A9:F3:19:D2:37:09:96:91:9E:0C:E8:D6:3D
X509v3 Subject Key Identifier:
91:24:F6:E0:5D:2B:7C:40:6A:C5:B1:EF:A9:75:BB:05:2D:F6:F1:2D
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Netscape Cert Type:
SSL Client, SSL Server
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
CPS: https://secure.comodo.net/CPS
X509v3 CRL Distribution Points:
URI:http://crl.comodoca.com/AAACertificateServices_2.crl
URI:http://crl.comodo.net/AAACertificateServices_2.crl
Authority Information Access:
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:webmail.chess.nl, DNS:exalg01.chess.int, DNS:webmail.exchange.chess-it.com
Signature Algorithm: sha1WithRSAEncryption
52:ec:5f:40:21:c6:e2:87:7e:06:fb:cb:f7:87:6b:76:1b:e6:
8d:6f:9b:2d:0b:05:36:ac:5c:b8:40:50:cf:8d:33:95:f0:0f:
e9:0e:62:2f:d4:2e:1a:84:73:87:63:e0:96:cf:16:e8:a1:8b:
86:49:f6:64:13:8a:c0:d8:29:30:4b:40:03:f4:e1:0c:ae:6e:
4c:d5:6f:40:93:a4:29:c6:5a:ba:ae:bb:ec:8d:0c:75:30:17:
25:de:bf:71:74:34:dc:47:16:38:ca:59:33:b8:31:66:5f:f1:
79:cf:24:66:66:38:f6:2b:f3:23:89:1a:11:ee:bb:9e:0b:5f:
29:bd:eb:85:05:6f:81:ff:c5:f9:ab:f3:88:f6:26:fe:0f:9d:
8b:36:c2:11:b9:98:90:74:15:b3:d6:cf:37:86:42:bd:92:27:
d8:41:b1:5a:e9:37:8b:c1:4e:28:41:74:18:83:d9:ed:a6:c9:
31:db:28:34:5d:43:6c:22:b5:23:ae:6d:f0:c3:fc:de:d5:7e:
f2:45:ff:80:df:b2:f9:48:c6:ce:64:92:e4:76:ed:c3:73:82:
5a:5b:71:6e:78:0e:18:1f:07:fa:ef:16:df:c6:f3:ea:67:b2:
78:0c:c5:71:0e:24:9d:ea:e5:e0:03:c5:7d:2f:7c:10:e2:eb:
ad:8f:1d:a2
Paul van Brouwershaven
webmail.chess.nl (chess.nl on: nl) - chess - NL
DNS:webmail.chess.nl,DNS:exalg01.chess.int,DNS:webmail.exchange.chess-it.com
webmail.chess.nl
exalg01.chess.int [dns error]
webmail.exchange.chess-it.com [other domain]
Serial: B3EA62E9256A4317FB3C28DF90007978
Not in crl version 1141 from Nov 5 02:04:18 2009 GMT
>>>>>>>>>>>>>>>>>>>> WHOIS <<<<<<<<<<<<<<<<<<<<
Registry: whois.iana.org
Results:
Domain chess.int not found.
This whois server only provides data for which IANA is authoritative,
including ".int" domains, ".arpa" domains, top level domains, and
some reserved names.
>>>>>>>>>>>>>>>>>>>> THE CERTIFICATE <<<<<<<<<<<<<<<<<<<<
Eddy Nigg
>> This item has been also taken to the CAB Forum and is discussed and
>> hopefully included with the Basic SSL Guidelines which are in the
>> making. Host-names and internal IP addresses provide *NO PROTECTION*
>> whatsoever and is pure snake oil. CAs which issue such certificates
>> deceive their customers and relying parties.
>>
> Sorry, this is just not true. The suppression of the browser warning
> is a value for which people pay. Without the certificate, the browser
> warning would reduce end user confidence in the service, essentially
> reducing security as perceived by the end user.
>
Sorry Florian, there is some nativity in your thinking. Digital
certificates are not meant to suppress warnings, they are meant to
provide point-to-point encryption and protection (in addition to
identification). The browser issues a warning when it detects that it
can't guaranty that protection. The warnings are not a conspiracy
between browser vendors and CAs so that you have to pay them (besides
that you don't even have to pay anymore these days ;-) ).
With today's VPN access points and WiFis, there is no problem accessing
corporate intranet networks from outside, certainly no problem from
employees and contractors from within the network. If I can get a
certificate for EXCHANGE.LOCAL or SERVER or 10.0.1.25 and you can get
another certificate from the same CA or another CA as well, there is NO
PROTECTION and the connection can be intercepted at will without any
relying party knowing.
Paul van Brouwershaven
Serial: D2D0DAD5A1C3E785844AA3C72CA2B191
Not in CRL number 2361 Last Update Nov 5 12:35:19 2009 GMT
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d2:d0:da:d5:a1:c3:e7:85:84:4a:a3:c7:2c:a2:b1:91
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com,
CN=UTN-USERFirst-Hardware
Validity
Not Before: May 30 00:00:00 2008 GMT
Not After : May 30 23:59:59 2009 GMT
Subject: C=GB/postalCode=M9 8FP, ST=Lancashire,
L=Manchester/streetAddress=Blackley/streetAddress=Delaunays Road, O=Manchester Cables Ltd (T/A) B3
Cable Solutions, OU=Information Systems, OU=Comodo InstantSSL Pro, CN=owa.b3cables.co.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:b5:1f:fd:37:d1:1e:db:cc:d5:0a:ac:cc:37:14:
2c:90:b5:d4:23:b7:2c:b0:0d:07:5d:81:e2:18:10:
6b:0e:79:3b:99:d0:78:ab:bf:9a:49:df:07:82:7f:
fa:d5:32:d3:5c:70:d5:9b:55:2b:06:31:28:41:eb:
b1:7f:04:55:99
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45
X509v3 Subject Key Identifier:
72:A2:F6:65:6E:A5:6F:8C:C4:6C:E6:A9:FF:BD:BF:42:A2:F4:A4:D4
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Netscape Cert Type:
SSL Client, SSL Server
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
CPS: https://secure.comodo.net/CPS
X509v3 CRL Distribution Points:
URI:http://crl.comodoca.com/UTN-USERFirst-Hardware.crl
URI:http://crl.comodo.net/UTN-USERFirst-Hardware.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/UTNAddTrustServerCA.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:owa.b3cables.co.uk , DNS:www.owa.b3cables.co.uk
Signature Algorithm: sha1WithRSAEncryption
ad:a1:3f:88:10:6e:3f:9a:77:f6:de:c3:56:63:64:70:2b:7f:
e1:e0:16:71:d9:b5:9c:83:e2:d2:f2:09:62:bb:dd:3c:06:db:
8f:5c:6d:a1:98:24:ad:9b:67:f0:39:33:76:03:58:20:83:92:
f7:ad:06:e4:2b:e2:20:0d:29:f2:83:55:5d:c0:d6:d7:44:6c:
9d:9d:1e:00:ae:ac:62:81:45:51:06:ba:02:10:4b:ea:58:a6:
84:78:74:25:59:10:9c:51:06:5e:46:7f:07:91:86:31:76:51:
6a:93:f7:fe:02:27:00:d9:60:f5:1e:72:91:f5:81:6f:9a:a9:
55:ae:80:b7:50:63:d6:4f:47:b4:f0:43:f8:ff:64:dd:56:6b:
0f:e2:42:e4:77:c7:89:65:dd:c9:bb:fc:8e:3b:db:24:e7:33:
cd:c3:75:77:94:39:00:ca:c8:3e:c0:53:db:af:c8:3a:41:86:
45:be:cd:c9:68:a9:2c:3c:41:de:7c:95:18:e7:ec:39:d1:da:
9f:fc:c2:6e:81:3b:86:fe:c4:55:a8:31:ab:6c:d1:e4:d6:39:
aa:bd:48:77:c8:96:1e:3b:b9:d2:45:7f:29:59:8c:27:1f:5c:
c8:15:44:86:51:8e:3e:5f:ad:3f:c3:e6:54:e8:dd:8a:e3:61:
c6:3c:81:6a
Florian Weimer
> What do you think of this certificate with the CN "owa.b3cables.co.uk\ ", again issued by Comodo.
>
> Serial: D2D0DAD5A1C3E785844AA3C72CA2B191
>
> Not in CRL number 2361 Last Update Nov 5 12:35:19 2009 GMT
It's expired anyway. Here's the blob for future reference:
-----BEGIN CERTIFICATE-----
MIIFbTCCBFWgAwIBAgIRANLQ2tWhw+eFhEqjxyyisZEwDQYJKoZIhvcNAQEFBQAw
gZcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY
aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMR8wHQYDVQQDExZVVE4tVVNFUkZpcnN0
LUhhcmR3YXJlMB4XDTA4MDUzMDAwMDAwMFoXDTA5MDUzMDIzNTk1OVowggEJMQsw
CQYDVQQGEwJHQjEPMA0GA1UEERMGTTkgOEZQMRMwEQYDVQQIEwpMYW5jYXNoaXJl
MRMwEQYDVQQHEwpNYW5jaGVzdGVyMREwDwYDVQQJEwhCbGFja2xleTEXMBUGA1UE
CRMORGVsYXVuYXlzIFJvYWQxNzA1BgNVBAoTLk1hbmNoZXN0ZXIgQ2FibGVzIEx0
ZCAoVC9BKSBCMyBDYWJsZSBTb2x1dGlvbnMxHDAaBgNVBAsTE0luZm9ybWF0aW9u
IFN5c3RlbXMxHjAcBgNVBAsTFUNvbW9kbyBJbnN0YW50U1NMIFBybzEcMBoGA1UE
AxMTb3dhLmIzY2FibGVzLmNvLnVrIDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC1
H/030R7bzNUKrMw3FCyQtdQjtyywDQddgeIYEGsOeTuZ0Hirv5pJ3weCf/rVMtNc
cNWbVSsGMShB67F/BFWZAgMBAAGjggIFMIICATAfBgNVHSMEGDAWgBShcl8mGyiY
Q5VdBzfVhZadS9LDRTAdBgNVHQ4EFgQUcqL2ZW6lb4zEbOap/72/QqL0pNQwDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIGwDBGBgNVHSAEPzA9MDsGDCsGAQQB
sjEBAgEDBDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9V
VE4tVVNFUkZpcnN0LUhhcmR3YXJlLmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21v
ZG8ubmV0L1VUTi1VU0VSRmlyc3QtSGFyZHdhcmUuY3JsMHEGCCsGAQUFBwEBBGUw
YzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQWRkVHJ1
c3RTZXJ2ZXJDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTA3BgNVHREEMDAughNvd2EuYjNjYWJsZXMuY28udWsgghd3d3cub3dhLmIz
Y2FibGVzLmNvLnVrIDANBgkqhkiG9w0BAQUFAAOCAQEAraE/iBBuP5p39t7DVmNk
cCt/4eAWcdm1nIPi0vIJYrvdPAbbj1xtoZgkrZtn8DkzdgNYIIOS960G5CviIA0p
8oNVXcDW10RsnZ0eAK6sYoFFUQa6AhBL6limhHh0JVkQnFEGXkZ/B5GGMXZRapP3
/gInANlg9R5ykfWBb5qpVa6At1Bj1k9HtPBD+P9k3VZrD+JC5HfHiWXdybv8jjvb
JOczzcN1d5Q5AMrIPsBT26/IOkGGRb7NyWipLDxB3nyVGOfsOdHan/zCboE7hv7E
Vagxq2zR5NY5qr1Id8iWHju50kV/KVmMJx9cyBVEhlGOPl+tP8PmVOjdiuNhxjyB
ag==
-----END CERTIFICATE-----
Florian Weimer
> I just found this certificate (exalg01.chess.int):
>
> webmail.chess.nl (chess.nl on: nl) - chess - NL
> DNS:webmail.chess.nl,DNS:exalg01.chess.int,DNS:webmail.exchange.chess-it.com
> webmail.chess.nl
> exalg01.chess.int [dns error]
> webmail.exchange.chess-it.com [other domain]
>
> Serial: B3EA62E9256A4317FB3C28DF90007978
>
> Not in crl version 1141 from Nov 5 02:04:18 2009 GMT
This one is still valid. Interesting.
-----BEGIN CERTIFICATE-----
MIIF2TCCBMGgAwIBAgIRALPqYuklakMX+zwo35AAeXgwDQYJKoZIhvcNAQEFBQAw
ezELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNV
BAMTGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wODA2MjQwMDAwMDBaFw0x
MTA2MjQyMzU5NTlaMIHuMQswCQYDVQQGEwJOTDEQMA4GA1UEERMHMjAxMSBOSjEW
MBQGA1UECBMNTm9vcmQtSG9sbGFuZDEQMA4GA1UEBxMHSGFhcmxlbTEZMBcGA1UE
CRMQTmlldXdlIEdyYWNodCA3ODEeMBwGA1UEEhMVNTAyMSwgMjkwMENBLCBIYWFy
bGVtMQ4wDAYDVQQKEwVjaGVzczEVMBMGA1UECxMMQ2hlc3MgQmVoZWVyMSYwJAYD
VQQLEx1Db21vZG8gVW5pZmllZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQd2Vi
bWFpbC5jaGVzcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMeF
EyNwMcZFU9BFy55K1pIPqQfBbBfHXEWzMaw9adMal5wz7panNMp0lPHc7PtZqosL
oo3Akyhk24/SB56k1X5jdj6kVXjLjH6+nSqULYsyBaqIs6PzyUHpQWhTYM14/r3Z
glkMf5CP4ABf653bLbOLesxFS7oWTYWa4ELPcCdf/YFeqp/qPkiLImDng4jXfi2t
bT0AyO0RyS5pqs9QA7mZtGXcsHQ3YSZ+dAkDJq6koOOwCiysmCPdF6sEabCkEUIE
fn0AM2XsbzQjaLGompavLFUrHxf4KgIgx7yHcGJJz5A6dReNMWnAYaKzuz9Oqi1j
nCOlQHcL8FvLnh0T8JcCAwEAAaOCAeIwggHeMB8GA1UdIwQYMBaAFDBD3GTNGVyp
8xnSNwmWkZ4M6NY9MB0GA1UdDgQWBBSRJPbgXSt8QGrFse+pdbsFLfbxLTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwEQYJYIZIAYb4QgEBBAQDAgbAMEYGA1UdIAQ/MD0wOwYMKwYBBAGy
MQECAQMEMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv
Q1BTMH8GA1UdHwR4MHYwOqA4oDaGNGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FB
QUNlcnRpZmljYXRlU2VydmljZXNfMi5jcmwwOKA2oDSGMmh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzXzIuY3JsMDQGCCsGAQUFBwEB
BCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tME0GA1Ud
EQRGMESCEHdlYm1haWwuY2hlc3MubmyCEWV4YWxnMDEuY2hlc3MuaW50gh13ZWJt
YWlsLmV4Y2hhbmdlLmNoZXNzLWl0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAUuxf
QCHG4od+BvvL94drdhvmjW+bLQsFNqxcuEBQz40zlfAP6Q5iL9QuGoRzh2Pgls8W
6KGLhkn2ZBOKwNgpMEtAA/ThDK5uTNVvQJOkKcZauq677I0MdTAXJd6/cXQ03EcW
OMpZM7gxZl/xec8kZmY49ivzI4kaEe67ngtfKb3rhQVvgf/F+avziPYm/g+dizbC
EbmYkHQVs9bPN4ZCvZIn2EGxWuk3i8FOKEF0GIPZ7abJMdsoNF1DbCK1I65t8MP8
3tV+8kX/gN+y+UjGzmSS5Hbtw3OCWltxbngOGB8H+u8W38bz6meyeAzFcQ4knerl
4APFfS98EOLrrY8dog==
-----END CERTIFICATE-----
Ian G
> On 05.11.2009 04:04, Ian G wrote:
>>> SSL certs should be issued only to the owner of the domain or party in
>>> control of the domain. (The requirements are explicit about that.)
>>> Given that non-existing domains don't have an owner, there must not be
>>> certs issued for them.
>>
>>
>>
>> But creating domains is a matter of editing /etc/hosts and DNS and so
>> forth.
>
> No, /etc/hosts doesn't count, only the public Internet DNS namespace
> managed by IANA/ICANN. Otherwise I would be, by the same logic, the
> "owner" of download.microsoft.com as soon as I create such an entry in
> my personal /etc/hosts. That's utter nonsense. Same goes for
> external.net or external.int.
It's not "utter nonsense" it's intellectual property. The claim that
IANA/ICANN controls the letters '.int' inside a corporation is
fundamentally based on intellectual property. Also, the notion that the
internetworking protocols cannot be used internally as seen fit is
something that is at odds with the entire history of the net.
As far as I can see, the policy does not back into the intellectual
property regime in that way. We would need either a policy statement
that clarifies Mozilla's position on IANA/ICANN's claim over the system,
or we could potentially refer to some PKIX-like document.
From what I recall, the appropriate RFC says that the CA should include
a section on intellectual property. However, this RFC section like the
rest was written with ... different objectives to yours ... so its use
is subtle.
However, help is at hand: it appears that this debate might be moot
because the CA in question has stated enough to clarify its intellectual
property position on domains.
Also, we may be in for some substantial help from Obama's administration
which is as we speak negotiating substantial powers to assist with
intellectual property violations as potentially experienced here in this
case:
http://www.boingboing.net/2009/11/03/secret-copyright-tre.html
Old chinese curse; be careful what you wish for. Mozilla and RIAA,
friends at last :)
>> for (a): If I have a corporate network and for some reason I'm using
>> ".int" for all my internal domains
>
> ... then that hypothetical you better get a clue. ".int" doesn't mean
> "internal", but "international", and is an official, real, assigned TLD.
By what law? But what policy? Does the RFC reach into a corporation
and tell it how to use bits & bytes?
> If you need a domain for yourself, including SSL, then register it.
> Costs $12/year.
> I don't think "ex.example.com" or "int.example.net" is that much harder
> to remember or type than "external.int" either. And you can get an SSL
> cert for it. And you won't get problems when you connect networks with
> partners.
Ah, this is a commercially biased position. Thank you for explaining
that the CAs need our support in selling their product, and this forum
exists to help them meet their sales targets.
Whatever happened to the end-user in Mozilla? When was the extinct
species last seen?
>> Where we would typically solve this with a *business approach* is to
>> set a contract condition.
>
> No, that would still be a violation of our policy. It governs all certs
> issued under a certain root. Otherwise it would be meaningless.
That it is meaningless in this case is definately an option!
iang
Ben Bucksch
> On 05/11/2009 12:42, Ben Bucksch wrote:
>> managed by IANA/ICANN. Otherwise I would be, by the same logic, the
>> "owner" of download.microsoft.com as soon as I create such an entry in
>> my personal /etc/hosts. That's utter nonsense. Same goes for
>> external.net or external.int.
>
>
LOL
> Mozilla and RIAA, friends at last :)
> By what law? But what policy? Does the RFC reach into a corporation
> and tell it how to use bits & bytes?
This is the funniest post I've seen from you so far.
You can use your /etc/hosts and your very own bits all you want,
including pushing them around using a microscope.
But you may still not get a CA cert for "download.microsoft.com" or
"intranet", because they are not yours on the Internet (defined by IETF
-> RFCs -> IANA -> ICANN -> registry) and you may not get *public*,
globally valid certs for that, as that may pose a threat to *others*.
But you can again take your microscope and make your own cert bits,
though, and put your own root cert bits in your own browsers all you
want. You got the source.
Eddy Nigg
> On 05.11.2009 16:24, Ian G wrote:
>> On 05/11/2009 12:42, Ben Bucksch wrote:
>>> No, /etc/hosts doesn't count, only the public Internet DNS namespace
>>> managed by IANA/ICANN. Otherwise I would be, by the same logic, the
>>> "owner" of download.microsoft.com as soon as I create such an entry in
>>> my personal /etc/hosts. That's utter nonsense. Same goes for
>>> external.net or external.int.
>>
>>
>> It's not "utter nonsense" it's intellectual property.
>
> LOL
>
>> Mozilla and RIAA, friends at last :)
>
>> By what law? But what policy? Does the RFC reach into a corporation
>> and tell it how to use bits & bytes?
>
> This is the funniest post I've seen from you so far.
Ben, why don't you simply ignore his comments?
>
> But you may still not get a CA cert for "download.microsoft.com" or
> "intranet", because they are not yours on the Internet (defined by
> IETF -> RFCs -> IANA -> ICANN -> registry) and you may not get
> *public*, globally valid certs for that, as that may pose a threat to
> *others*.
>
Don't waste your time trying to explain... Ian knows all that himself,
he just has apparently other intentions here. Say "Red" and he will say
"Blue", say "Angel" and he'll say "Satan"....just get used to it.
Ian G
> On 05.11.2009 16:24, Ian G wrote:
>> On 05/11/2009 12:42, Ben Bucksch wrote:
>>> managed by IANA/ICANN. Otherwise I would be, by the same logic, the
>>> "owner" of download.microsoft.com as soon as I create such an entry in
>>> my personal /etc/hosts. That's utter nonsense. Same goes for
>>> external.net or external.int.
>>
>>
>
> LOL
>
>> Mozilla and RIAA, friends at last :)
>
>> By what law? But what policy? Does the RFC reach into a corporation
>> and tell it how to use bits & bytes?
>
> This is the funniest post I've seen from you so far.
I'm glad you're having fun :) There is a slightly serious aspect to it
though, as many jobs and revenues and national-state projects are based
on it.
> You can use your /etc/hosts and your very own bits all you want,
> including pushing them around using a microscope.
>
> But you may still not get a CA cert for "download.microsoft.com" or
> "intranet", because they are not yours on the Internet (defined by IETF
> -> RFCs -> IANA -> ICANN -> registry) and you may not get *public*,
> globally valid certs for that, as that may pose a threat to *others*.
So your point is that when IETF -> RFCs -> IANA -> ICANN -> registry
states that a TLD is now in operation and is awarded as the intellectual
property of the appropriate registry, this is to be respected by all CAs?
OK, that will almost certainly work in this case because comodo respects
that already in the CPS. It will probably work in the larger case as it
seems reasonable to draw a line in the sand at that point.
However this leaves the entire scope of non-TLDs. So if I start issuing
my.internal.dom.iang, is that outside the reach of the IETF -> RFCs ->
IANA -> ICANN -> registry -> RIAA -> DCMA/takedown -> .... and other
IP-mobsters?
Can I use the efficient services of the CAs to help me secure my network
there?
Can we clarify this? Or are we saying that we are passing the entire
extent of the domain name system into the intellectual property powers
of the above-mentioned cartel?
Regardless of the mirth, this is a serious question. Apparently
public-facing CAs are regularly selling certificates for non-FQDNs into
corporations.
(Just to point out that it's not me to blame...)
> But you can again take your microscope and make your own cert bits,
> though, and put your own root cert bits in your own browsers all you
> want. You got the source.
lol... true.
iang
Ian G
> Don't waste your time trying to explain... Ian knows all that himself,
> he just has apparently other intentions here. Say "Red" and he will say
> "Blue", say "Angel" and he'll say "Satan"....just get used to it.
Now you're getting it. It is not acceptable to simply achieve consensus
and go out and burn witches coz we all like that. The point is that the
policy does not clarify whether CAs have to restrict themselves to the
TLD system or not. Nor does the audit system.
It's not personal, it's just one of those things that were missed out.
One could speculate that this is deliberate, because some CAs are making
money off of it and others haven't seen it. But that would be idle
speculation.
So what's your call? Change the policy to clarify? Refer it to some
other forum? Ignore the problem? Or go and burn some witches.
Here's a suggestion from Satan. Add to clause 7:
* certificates issued for internal usage must not be issued over
domain names that use (insert proper langauge) TLDs registed by IANA. A
separate subroot should be used for this, and the naming should be made
so as to be obviously not confusing with any TLD.
Plenty of stuff to burn there....
iang
Florian Weimer
> On 11/04/2009 09:31 PM, Florian Weimer:
>> Does the CPS really say that? Where?
>>
>
> If you don't mind, the Mozilla CA Policy requires under section 7:
>
> /for a certificate to be used for SSL-enabled servers, the CA takes
> reasonable measures to verify that the entity submitting the
> certificate signing request *has registered the domain(s) referenced
> in the certificate /or/ has been authorized by the domain registrant
> to act on the registrant's behalf*;/
>
>
> Here is the link to the policy:
> http://www.mozilla.org/projects/security/certs/policy/
Okay, then Mozilla has got a significant problem because some CAs
issue certificates for domains not delegated from the ICANN root.
These CA roots should not be on Mozilla's root CA list.
Kyle Hamilton
into it, and issue certificates from that root to the boxes that need
it?
Oh yeah, because people use computers for more than one purpose. A
home machine can be used to VPN into work.
Wake up, Mozilla. Your policy is not useful to the users.
On Thu, Nov 5, 2009 at 3:52 AM, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Eddy Nigg:
>
>> This item has been also taken to the CAB Forum and is discussed and
>> hopefully included with the Basic SSL Guidelines which are in the
>> making. Host-names and internal IP addresses provide *NO PROTECTION*
>> whatsoever and is pure snake oil. CAs which issue such certificates
>> deceive their customers and relying parties.
>
> Sorry, this is just not true. The suppression of the browser warning
> is a value for which people pay. Without the certificate, the browser
> warning would reduce end user confidence in the service, essentially
> reducing security as perceived by the end user.
>
> (The system doesn't do much else anyway, but at least this type of
> service is provided by CAs.)
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Eddy Nigg
>
> Now you're getting it. It is not acceptable to simply achieve
> consensus and go out and burn witches coz we all like that.
What's wrong with achieving consensus? Others fight for years to achieve
that.
> Here's a suggestion from Satan. Add to clause 7:
>
> * certificates issued for internal usage must not be issued over
> domain names that use (insert proper langauge) TLDs registed by IANA.
> A separate subroot should be used for this, and the naming should be
> made so as to be obviously not confusing with any TLD.
It's been in the problematic practices for quite some time, it's a
candidate for the policy (or by proxy if it will be in the Basic SSL
Guidelines). Your contributions would be perceived very differently if
you would do as above. Simply say, that you think that we need to add to
the policy.......
Eddy Nigg
> Okay, then Mozilla has got a significant problem because some CAs
> issue certificates for domains not delegated from the ICANN root.
> These CA roots should not be on Mozilla's root CA list.
>
Correct. We are working on that by and through various means.
Florian Weimer
> Now you're getting it. It is not acceptable to simply achieve
> consensus and go out and burn witches coz we all like that. The point
> is that the policy does not clarify whether CAs have to restrict
> themselves to the TLD system or not. Nor does the audit system.
Eh, the policy is pretty clear on that. Its application has created
ambiguity, though, because there's a track record of not requiring DV
from CAs.
Dave Miller
<just...@mozilla.com> wrote:
> In article <kbednVCCENx9c2zX...@mozilla.org>, Eddy Nigg
> <eddy...@startcom.org> wrote:
>
> > On 11/04/2009 11:13 PM, Dave Miller:
> > >
> > > Giganews says the original message got nailed as a binary post because
> > > of the included base64-encoded SSL certificate.
> > >
> >
> > Specially on these news groups this can happen from time to time. Is
> > this something which can be fixed?
>
> Not unless we host it all ourselves (which has been discussed, and will
> probably happen someday, but not anytime soon probably.
Actually, looks like it is getting fixed. I just got this from
Giganews support:
----8<----
I agree, it was a false positive. The SSL cert looked enough like
mime-encoded data to trip the filter. I've asked our programmers to
look into tightening the filter to prevent this in the future.
----8<----
--
Dave Miller
Systems Administrator, Mozilla Corporation
Eddy Nigg
> Actually, looks like it is getting fixed. I just got this from
> Giganews support:
>
> ----8<----
> I agree, it was a false positive. The SSL cert looked enough like
> mime-encoded data to trip the filter. I've asked our programmers to
> look into tightening the filter to prevent this in the future.
> ----8<----
>
Excellent! Thanks a lot for your effort!
PhoenixMylo
inadvertantly send private replies to. I will paraphrase my replies
to those two individuals publicly:
In short, 10.x.x.x or myserver or myserver.local (at least until such
time ans IANA/ICANN sells .local to the highest bidder) are non-
routable over the internet. If I, as an admin with 1000 users on 3000
different devices wish to obtain a CA sign cert to suppress browser
errors for sites on my LAN for my users wish to pay a CA for that
convenience rather than paying IANA/ICANN or one of there flunkies
(who incidentally perform zero verification when I buy a domain), be
prevented from doing so? Because of vulnerabilities in the DNS
system, or possibly hi-jacking of a HOSTS file? It seems to me that
DNS vulnerabilities and/or the ability of a malevolent party to alter
a HOSTS file are the responsibility of those who code DNS servers and
operating systems respectively. Not my responsibility, nor that of
the CA.
Eddy Nigg
> In short, 10.x.x.x or myserver or myserver.local (at least until such
> time ans IANA/ICANN sells .local to the highest bidder) are non-
> routable over the internet. If I, as an admin with 1000 users on 3000
> different devices wish to obtain a CA sign cert to suppress browser
> errors for sites on my LAN for my users wish to pay a CA for that
> convenience rather than paying IANA/ICANN or one of there flunkies
> (who incidentally perform zero verification when I buy a domain), be
> prevented from doing so?
If the TLD doesn't really exists, than yes, you should not receive a
certificate from a public CA. You can however use your own trusted root
for your internal network, which incidentally really would protect you.
Or use your real domain and reference the internal hostnames to the
internal IPs. The DNS server doesn't have to be publicly accessible.
> Because of vulnerabilities in the DNS
> system, or possibly hi-jacking of a HOSTS file?
Yes! That's exactly the reason why SSL certificates used for
point-to-point encryption MUST be validated, otherwise how would you
prevent a man-in-the-middle attack? Those vulnerabilities have been
demonstrated and even practically used. That's THE number one reason why
you use certificates from CAs and not your own home-brew. Otherwise why
do you think the browser warns you in such a bold way when encountering
an untrusted root?
> It seems to me that
> DNS vulnerabilities and/or the ability of a malevolent party to alter
> a HOSTS file are the responsibility of those who code DNS servers and
> operating systems respectively. Not my responsibility, nor that of
> the CA.
>
With today's wifi access points, no flaw in any code has to exist in
order to pwn you. But also corporate VPN access points are at risk and
even threats from within the corporate network (like a grumbling
employee or contractor).
Now, just consider you got a certificate for myserver.local from a CA.
Your browser will trust it, right? You would trust your browser too, right?
But hey, if you can get a certificate for myserver.local, so can I,
right? If I can get a certificate referencing a hostname at your
network, than anybody can do the same, right? So we all have
certificates for myserver.local and are happily using them....or?
If an attacker has a certificate for your machine at your network, he
may be in the position to attack you by various means. Unfortunately, an
attacker has compromised your connection and is using a certificate for
myserver.local issued by a public CA. Just, you wouldn't even know,
because you trust your browser and the CA.
Gervase Markham
> It's not "utter nonsense" it's intellectual property. The claim that
> IANA/ICANN controls the letters '.int' inside a corporation is
> fundamentally based on intellectual property. Also, the notion that the
> internetworking protocols cannot be used internally as seen fit is
> something that is at odds with the entire history of the net.
No-one is claiming either that ICANN owns the letters ".int" or that you
can't use networking protocols in any way you see fit inside your own
company. They are merely claiming that you cannot use valid external
names internally and expect to be given certificates for them signed by
publicly-trusted roots.
Gerv
Gervase Markham
> Okay, then Mozilla has got a significant problem because some CAs
> issue certificates for domains not delegated from the ICANN root.
> These CA roots should not be on Mozilla's root CA list.
Which ones?
Gerv
Ian G
> On 05/11/09 15:24, Ian G wrote:
>> It's not "utter nonsense" it's intellectual property. The claim that
>> IANA/ICANN controls the letters '.int' inside a corporation is
>> fundamentally based on intellectual property. Also, the notion that the
>> internetworking protocols cannot be used internally as seen fit is
>> something that is at odds with the entire history of the net.
>
> No-one is claiming either that ICANN owns the letters ".int" or that you
> can't use networking protocols in any way you see fit inside your own
> company. They are merely claiming that you cannot use valid external
> names internally
That is what is meant, precisely.
When we say ICANN owns the letters ".int" this is a shorthand for a very
complicated situation generally referred to by the other shorthand of
intellectual property.
Just like when we say that Apple owns the rights to the Beatles songs.
This doesn't mean you can't sing _Love me do_ in the shower. But it
does mean you cannot sing the songs in an external and public performance.
So what we are about today is figuring out the boundary between the
shower and the public performance, for ".int". It's not that hard, the
bigger companies all know how this works, as we can see from Comodo's
documentation.
> and expect to be given certificates for them signed by
> publicly-trusted roots.
The question of whether CAs respect those rights is an implementation
detail, right. First we establish the right. Then ask the CAs to
preserve that right. No biggie.
iang
Benjamin Smedberg
> When we say ICANN owns the letters ".int" this is a shorthand for a very
> complicated situation generally referred to by the other shorthand of
> intellectual property.
This really has nothing to do with intellectual property. It has to do with
the trust relationship between the internet DNS system (with ICANN at the
top level), CAs, and Mozilla. Mozilla should (does?) require that CAs only
issue certificates for valid public DNS, which means TLDs that are
recognized by ICANN.
There are no "rights" or legal restrictions even vaguely relating to
property, copyright, or trademark, which is the typical domain called
"intellectual property". This is merely a decision that the default trust
Mozilla delegates to CAs is based on the public DNS system.
--BDS
Ian G
> On 11/6/09 9:22 AM, Ian G wrote:
>
>> When we say ICANN owns the letters ".int" this is a shorthand for a very
>> complicated situation generally referred to by the other shorthand of
>> intellectual property.
>
> This really has nothing to do with intellectual property. It has to do with
> the trust relationship between the internet DNS system (with ICANN at the
> top level), CAs, and Mozilla.
Right, both, same thing. Intellectual property is that thing about the
trust transmitted between organisations through agreements over such
intangible things as domains.
> Mozilla should (does?) require that CAs only
> issue certificates for valid public DNS, which means TLDs that are
> recognized by ICANN.
Yes, the question at hand is whether Mozilla should ask the CAs to
respect the monopoly on DNS names awarded to the TLD registries by
ICANN, and whether to extend those rights such that the particular
question is resolved.
Right now, Mozilla does not. It does however make certain implications
in the policy.
> There are no "rights" or legal restrictions even vaguely relating to
> property, copyright, or trademark, which is the typical domain called
> "intellectual property".
The general field of intellectual property is not restricted to the
formal law-regulated tuplet of patents, copyrights or trademarks. IP
can be created by contract, managed by contract, sold by contract. It
often rests on a final registry created by law, but not always.
Think of it this way: a domain name is a property that is managed by a
registry. It is not a physical (car) or real (land) property. As it is
intangible, it falls into the "intellectual property" general basket. QED.
You can buy my domain, right? That makes it intellectual property. The
question of whether you can use my domain in your internal network is a
question of whether you respect the reach of those property rights.
> This is merely a decision that the default trust
> Mozilla delegates to CAs is based on the public DNS system.
You are using all the right words, just not wanting to accept the label.
That's fine, we can do that, security is full of such refusal to turn
the coin around and look at the other face. But the bigger CAs won't be
with you in that dance.
They're around 15 years ahead on this question. For various complicated
reasons I won't go into, mozilla only has to say the magic words, and
this is a done deal (see thread for the evidence).
Or we could dance around the issue, crafting the words without using the
reality, and we'll set ourselves up for another decade of confusion and
unforseen circumstances.
iang
Justin Dolske
> On 06/11/2009 16:06, Benjamin Smedberg wrote:
>> This really has nothing to do with intellectual property.
I agree with Benjamin. IP is a separate thing, and trying to shoehorn it
in here is a bad idea because it's such a polarizing issue. It doesn't
help describe the situation, but rather muddies the waters with people's
preconceived opinions about IP.
Justin
Kyle Hamilton
cut out all CAs that don't comply by that date. Regardless of the
"track record of not requiring DV", this is very much like the court
system relying on precedent for some case and the
legislature/executive being able to move to block it.
-Kyle H
Daniel Veditz
> then why not create an internal build of Firefox, embed your own root
> into it, and issue certificates from that root to the boxes that need
> it?
You don't need a special build, of course. Anyone can easily add a new
root into modern desktop browsers. It may be less easy with other
internet devices (phones, for example).
Daniel Veditz
> What do you think of this certificate with the CN
> "owa.b3cables.co.uk\ ", again issued by Comodo.
>
> Serial: D2D0DAD5A1C3E785844AA3C72CA2B191
>
> Not in CRL number 2361 Last Update Nov 5 12:35:19 2009 GMT
CA's can prune expired certs from their CRLs to keep the size down. The
fact that it's not in a recent CRL doesn't tell whether it was or wasn't
in the past.
The extra space renders that domain unusable (in Firefox, at least) so
it's a bit of a self-limiting problem, but I wouldn't crucify a CA for a
trailing space issue. It's a bug they should fix, but let's stick to the
more substantive examples you raised.
Florian Weimer
> I'm more than happy to set a policy, then set a cut-off date, and then
> cut out all CAs that don't comply by that date. Regardless of the
> "track record of not requiring DV", this is very much like the court
> system relying on precedent for some case and the
> legislature/executive being able to move to block it.
Sure, what would be needed to move in that direction?
It's probably not possible to require DV per se, but I would
appreciate if Mozilla could send a more consistent message regarding
domain ownership/control requirements.
I really don't understand what the CAs are doing here. Are they
really issuing certs for seb.fin right now (brand picked arbitrarily,
but with non-obviousness in mind)? The other side of the coin is that
Mozilla's unknown certificate UI was very bad in the 3.0 release, so I
can see why there's a business case for certs for not globally
existing domains.