Re: SHA1 root CA

On Wed, 1 Mar 2017 00:44:54 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > are root (Enterprise) CA certificates wich are based on SHA1 handled > as untrusted by Firefox 51? The end certificate is sign using sha256 > and trusted by a

Re: SHA1 root CA

On Wed, 1 Mar 2017 02:21:21 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > so why is Firefox complaining with this error message: > > SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED Can you be more specific? Where are you seeing that error

Re: SHA1 root CA

On Wed, 1 Mar 2017 02:36:22 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > when connecting to a webserver > > screenshot of the error message: http://imgur.com/a/BIQUm It would be helpful if you told us which webserver. The error message

Re: Leaking private keys through web servers

On Wed, 12 Jul 2017 10:47:51 -0400 Ryan Sleevi wrote: > One challenge to consider is how this is quantified. Obviously, if you > reported to Comodo the issue with the key, and then they issued > another certificate with that key, arguably that's something Comodo > should have

Leaking private keys through web servers

Hello, I recently did an investigation where I tried to simply download private keys from web servers with common filenames. I collected these filenames simply from common tutorials on the web (server.key, privatekey.key, myserver.key, key.pem and [hostname].key with and without www). In several

Re: Certificate with invalid dnsName issued from Baltimore intermediate

More dotdot-certificates: https://crt.sh/?id=34528113 for autodiscover.amphenolcanada..com Expired 2012 issued by Geotrust (aka symantec) https://crt.sh/?id=3478078 for PDC-LIB-WEB1.RBI1.rbi..in Expired 2016 issued by Institute for Development and Research in Banking Technology

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, 18 Jul 2017 19:29:10 + Jeremy Rowley via dev-security-policy wrote: > Some of these certs are really old. Some of them are also not so old and still valid. All from GoDaddy: https://crt.sh/?id=22835635 https://crt.sh/?id=8216255 This one

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On Tue, 18 Jul 2017 21:43:28 +0200 Hanno Böck via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > It has this commonname: > commonName= .guidedstudies.com > > Well... that's also not a valid hostname... And of course it's not t

Re: Certificates with invalidly long serial numbers

On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-security-policy wrote: > FWIW - In the case of Telecom Italia, they have a commercial CA > product has a bug in it that occasionally causes this issue. They > may need some time for the software to be

Re: On GitHub, Leaked Keys, and getting practical about revocation

On Wed, 21 Jun 2017 10:40:01 -0700 (PDT) Matthew Hardeman via dev-security-policy wrote: > Through a little Google digging, I find numerous comments and > references from well informed parties going back quite several years > lamenting the poor state of

Certificate with Debian weak key issued by Let's Encrypt

Hi, A while ago I tested how some CAs would react to certificate requests with debian weak keys. I was able to get a certificate from Let's Encrypt with a debian weak key. Here is it: https://crt.sh/?id=173588030 I reported this to Let's Encrypt. They told me that they are aware they weren't

Lack of CAA checking at Comodo

Hi, On saturday I was able to receive a certificate from comodo depsite the subdomain having a CAA record only allowing Let's Encrypt as the CA. Here's the cert: https://crt.sh/?id=207082245 I have by now heard from multiple other people that confirmed the same. Seems right now Comodo isn't

CAA reporting support and tests?

Hi, I was wondering how a CAA reporting endpoint should react and wanted to test it. However none of the CAs I tested seems to support reporting yet. Is anyone aware of a CA that does CAA reporting? (either via mail or https or both.) If no reporting on a live CA is in place is at least anyone

Re: Possible future re-application from WoSign (now WoTrus)

FWIW my opinion: I don't think there should be a lifetime or long term ban for people or companies that have operated a bad CA in the past. However I do believe that the way Wosign representatives on this list acted in the past was often dishonest and highly problematic. If Wosign continues to

Fw: StartCom temination announcement

I guess it's interesting for the community, this is the message I just got as a former StartCom customer. Begin forwarded message: Date: Sat, 2 Dec 2017 06:24:44 + From: StartCom CertMaster Subject: StartCom temination announcement StartCom temination

Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

Hi, I guess this is of interest to the members of this list: https://www.golem.de/news/microsoft-dynamics-365-wildcard-certificate-with-a-private-key-for-everyone-1712-131544.html https://medium.com/matthias-gliwka/microsoft-leaks-tls-private-key-for-cloud-erp-product-10b56f7d648 tl;dr Microsoft

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Fri, 8 Dec 2017 16:43:48 -0700 Wayne Thayer via dev-security-policy wrote: > The root CA is ultimately responsible for subordinate CAs it has > signed. I see a problem with that, as this is far from obvious. If a random person discovers a problem

Re: On the value of EV

Hi, On Mon, 11 Dec 2017 11:01:10 -0800 (PST) Ryan Sleevi via dev-security-policy wrote: > I suppose this is both a question for policy and for Mozilla - given > the ability to provide accurate-but-misleading information in EV > certificates, and the effect

Certificate with duplicate commonname

Hi, This certificate has a duplicate commonname: https://crt.sh/?id=242683153=problemreporting This was pointed out by Mattias Geniar: https://twitter.com/mattiasgeniar/status/924705516974112768 I'm not entirely sure if the wording of the BRs forbid this (they say the CN field must contain a

Unrevoked/unexpired certificate with Debian Weak Key

Hi, Yesterday was the 10y anniversary of the Debian OpenSSL random number generator bug. A few days ago I did a re-check of the CT logs for vulnerable keys. I found one unexpired, unrevoked certificate issued by a CA called "QuoVadis". I reported it and it's been revoked, they told me they'll

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 14:43:21 + Jeremy Rowley via dev-security-policy wrote: > Without the private key, im not sure how we're supposed to confirm > key compromise. I've pinged a few people with the right skillset to try to extract the key. But if there

Key compromise and root cert with shared key in german lawyer communication software (beA)

Hi, The german bar association has a software for secure communication between lawyers called "besonderes elektronisches Anwaltspostfach" (beA). They used a local https server run on the client with a valid certificate for bealocalhost.de (the domain resolves to 127.0.0.1). This means the

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Thanks, I also got it in the meantime and submitted it to CT: https://crt.sh/?id=287530764 Bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=1427034 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 04:19:58 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > Side question: why wasn't the certificate from DigiCert logged into > Certificate Transparency logs when it was issued and it had to be > discovered this way? There's no

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Sun, 24 Dec 2017 23:07:56 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > on any computer with BattleNet installed and active go to this url: > > https://127.0.0.1:22886/ > and currently it uses this certificate... which doesn't appear on >

Re: DYMO Root CA installed by Label Printing Software

Hi, On Tue, 09 Jan 2018 21:04:34 + Nicholas Humfrey via dev-security-policy wrote: > What is the correct way for them to achieve what they are trying to > do? > > Would it be better to use a self-signed localhost certificate (same > subject and >

Re: Google OCSP service down

Hi, On Sun, 21 Jan 2018 12:09:23 -0800 (PST) Ryan Hurst via dev-security-policy wrote: > We maintain contact details both within our CPS (like other CAs) and > at https://pki.goog so that people can reach us expeditiously. In the > future if anyone needs

Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

Hi, Comodo ITSM (IT Service Management Software) runs an HTTPS server on localhost and port 21185. The domain localhost.cmdm.comodo.net pointed to localhost. It is obvious that with this setup the private key is part of the application and thus compromised. With advanced next generation key

Certificates with 2008 Debian weak key bug

Hi, I searched crt.sh for valid certificates vulnerable to the 2008 Debian weak key bug. (Only 2048 bit.) Overall I found 5 unexpired certificates. Two certificates by Certum (reported on Saturday, Certum told me "We have taken necessary steps to clarify this situation as soon as possible",

Re: Certificate for com and it

On Thu, 8 Feb 2018 15:50:08 + Gervase Markham via dev-security-policy wrote: > In this case, the certificates are revoked in Firefox via OneCRL and > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be > noticed. Hi Gerv, Independent

Certificate for com and it

This certificate https://crt.sh/?id=282908507 is issued for the names "com" and "it". It also contains other suspicious hostnames: sip.fideuram sip.consule sip.consultant.fideura I don't think these TLDs exist. Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of

Re: Certificates with 2008 Debian weak key bug

On Mon, 5 Feb 2018 12:07:06 -0500 Eric Mill via dev-security-policy wrote: > WoSign and StartCom are untrusted, but Certum is still trusted, right? Yes. In case that was unclear: The sentence "As we all know these are no longer trusted by Mozilla, ..."

Re: Certificate for com and it

Hi, On Tue, 6 Feb 2018 16:56:48 +0100 Kurt Roeckx via dev-security-policy wrote: > I should probably more clear, the certificates of the CA have been > revoked. I'm wondering what that means. Is a revoked intermediate cert a license for operating a yolo

Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Hi, Tavis Ormandy recently tweeted this: https://twitter.com/taviso/status/938503794098180096 What's happening here: The software battle.net by Blizzard has a domain localbattle.net that points to localhost, allowing the software to serve content there. The content is served via HTTPS with a

Re: localhost.megasyncloopback.mega.nz private key in client

On Sun, 5 Aug 2018 15:23:42 -0500 Alex Cohn via dev-security-policy wrote: > The certificate [1] in the GitHub link you posted was issued by > Comodo, not by GeoTrust. The two share a private key, though, so both > the Comodo and GeoTrust certs should be considered compromised at > this point.

Re: localhost.megasyncloopback.mega.nz private key in client

On Thu, 9 Aug 2018 13:24:48 + Jay Wilson via dev-security-policy wrote: > The certificate has been revoked. > The bounce issue has been escalated to resolve. Really? $ ocspverify 630835231.crt Response verify OK 630835231.crt: good This Update: Aug 4 15:34:50 2018 GMT

New certificate from compromised key

Hi, Some of you may remember the discussion about embedded private keys in Blizzard's battle.net software here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/pk039T_wPrI/VYi629oGCwAJ One of the certificates with a compromised key back then was issued by Digicert:

Trustico code injection

Hi, On twitter there are currently some people poking Trustico's web interface and found trivial script injections: https://twitter.com/svblxyz/status/969220402768736258 Which seem to run as root: https://twitter.com/cujanovic/status/969229397508153350 I haven't tried to reproduce it, but it

Re: Allowing WebExtensions to Override Certificate Trust Decisions

Hi, On Tue, 27 Feb 2018 09:20:33 -0700 Wayne Thayer via dev-security-policy wrote: > This capability existed in the legacy Firefox extension system that > was deprecated last year. It was used to implement stricter security > mechanisms (e.g. CertPatrol)

Comodo and Trustico (was Re: Trustico code injection)

On Fri, 2 Mar 2018 16:10:52 +0900 Hector Martin 'marcan' via dev-security-policy wrote: > And what does Comodo think of all of this? I'd like to second this. When I wrote the original mail in this thread I considered adding questions to Comodo, but I

Re: How harsh (in general) should Mozilla be towards CAs?

On Fri, 9 Nov 2018 14:56:41 +0100 Jakob Bohm via dev-security-policy wrote: > However there are also some very harsh punishments handed out, such as > distrusting some CAs (most notably happened to Symantec and WoSign, > but others are also teetering), and distrusting auditors (most notably >

AlwaysOnSSL web security issues

Hi, AlwaysOnSSL was a free certificate authority operated by CertCenter. I recently noticed that their main webpage was gone, but pieces of the service were still online. I immediately found a few web security issues. I reported those to certcenter and digicert (which is the root CA their

Re: DarkMatter Concerns

This statement repeats the claim that you wrote here previously, specifically: "I want to assure you that DarkMatter's work is solely focused on defensive cyber security, secure communications and digital transformation." The statement does not comment on the Reuters article, but it is in stark

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

On Thu, 24 Jan 2019 11:14:11 + "Buschart, Rufus via dev-security-policy" wrote: > You are right, of course there are mandatory RFC to take into > account. But there is - to my knowledge - no RFC that says, you MUST > NOT issue a certificate to a domain that could be interpreted as an >

Re: Certinomis Issues

Hi, I just saw this on twitter: https://twitter.com/sam280/status/1133008218677022722 And later in the thread: https://twitter.com/sam280/status/1133112699385257985 The first tweet points out that Certinomis seems to use wrong OIDs in their certs (quote "Of course the first invalid #PSD2 #QWAC

Re: Sectigo-issued certificates with concerningly mismatched subject information

On Sun, 26 Jan 2020 01:59:33 -0800 (PST) Ian Carroll via dev-security-policy wrote: > These certificates expired in 2019 and are thus no longer a problem, > but they were actively used by the customer (e.infinityspeakers.com > still serves one of them) and it does not appear anyone has noticed.

Re: AIA CA Issuers URL gives 403 (Microsoft)

Hi, On Mon, 11 May 2020 10:53:26 +0200 Hanno Böck via dev-security-policy wrote: > I did some checks on certificates and their AIA sections and noticed > that several Microsoft certificates were referencing intermediate > certificates in the "CA Issuer" field that give a 4

Re: Mozilla's Expectations for OCSP Incident Reporting

On Wed, 13 May 2020 02:29:07 + Peter Gutmann via dev-security-policy wrote: > Following up on this, would it be correct to assume that, since > no-one has pointed out any impact that this had on anything, that > it's more a certificational issue than anything with real-world > consequences?

Re: AIA CA Issuer field pointing to PEM encoded certs

Update: All 4 CAs have corrected the certs and are now serving DER encoded intermediates at the URLs. -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

AIA CA Issuers URL gives 403 (Microsoft)

I did some checks on certificates and their AIA sections and noticed that several Microsoft certificates were referencing intermediate certificates in the "CA Issuer" field that give a 403 error. http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt

AIA CA Issuer field pointing to PEM encoded certs

Hi, As I mentioned in my previous mail I found some instances of CAs pointing to PEM encoded certificates in their AIA fields, while they should be DER encoded. I found such instances for 4 CAs, I'll list them with one example cert and the URL of the referenced intermediate.

AIA CA Issuers field

Hi, I have been doing some checks on certificates with the AIA Issuers field. I already reported certificates with a 403 error on the HTTP url of the intermediate (see earlier mail). Now there's more stuff to be found and I'm wondering: * Are there rules that CAs must adhere to in regards to

Re: Mozilla's Expectations for OCSP Incident Reporting

On Fri, 15 May 2020 10:13:01 -0400 Lee via dev-security-policy wrote: > How is this situation different from the time when the google ocsp > service was down? Maybe some clarification here: The Google OCSP was the OCSP for end entity certificates. The Identrust OCSP was the OCSP server for

Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

On Sat, 21 Mar 2020 19:20:27 + Nick Lamb via dev-security-policy wrote: > Rather than mint an RSA key pair and self-signed certificate to > bootstrap each install, they just supply a (presumably randomly > generated) key and certificate right in the install data. FWIW: Given that with the

CA Issuer AIA URL content types

Hi, Doing some analysis on the AIA CA Issuer field I checked the content types the certificates are served. These are the AIA issuer fields in the top 1 from the alexa list, so this is incomplete. According to RFCs application/pkix-cert is the only correct content-type. However the majority

Non-DER certificate (PKCS #7) in CA Issuers AIA field

Just reported this to Chunghwa Telecom Co., Ltd.: -- I'm contacting you about a problem with the certificate for *.hinet.net, as it can be found here [1]. The Authority Information Access / CA Issuers field points to: http://repository.publicca.hinet.net/certs/IssuedToThisCA.p7b

Re: CA Issuer AIA URL content types

Hi, On Fri, 22 May 2020 09:55:22 -0400 Ryan Sleevi via dev-security-policy wrote: > Could you please cite more specifically what you believe is wrong > here? This is only a SHOULD level requirement. I think I said that more or less: > > I'm not going to file individual reports for the CAs.

Re: Intermediate common name ambiguous naming

Hi, On Fri, 11 Dec 2020 10:51:44 + Burton via dev-security-policy wrote: > The common name of the Let's Encrypt R3 intermediate certificate ( > https://crt.sh/?id=3479778542) is in my opinion short and ambiguous. > It doesn't have any information in common name that can identify the >