This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
EKU and CN=hmrcset.trustis.com:
https://crt.sh/?id=50773741=cablint
It lacks the SAN extension, but that doesn't excuse it from the ban on
SHA-1!
Its issuer is trusted for serverAuth by Mozilla:
This currently unrevoked cert has the serverAuth EKU and
dNSName=qvsslrca3-v.quovadisglobal.com:
https://crt.sh/?id=83114602
Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=1333
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
On 27/03/17 23:12, Andrew Ayer wrote:
My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away. If the sub-CA is created as a backup that
On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?
Actually, I think
On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:
On 28/03/17 12:21, Rob Stradling wrote:
Increased attack surface. An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being
On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote:
Section 5.3.1 of policy 2.4.1 defines what it means to be technically
constrained for email sub-CAs (those with id-kp-emailProtection). It says:
"If the certificate includes the id-kp-emailProtection extended key
usage, then
On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote:
On 27/03/17 22:12, Andrew Ayer wrote:
[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67
]
This has now been added to the policy 2.5 draft with a one-week deadline.
Gerv
Gerv,
Mozilla also
On 13/04/17 14:50, Gervase Markham wrote:
On 12/04/17 21:21, Rob Stradling wrote:
Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB. Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?
There is:
Thanks Gerv. :-)
On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote:
Hi Rob,
You either have a great memory or good search-fu; well done for digging
this out!
On 12/04/17 22:14, Rob Stradling wrote:
Gerv, FYI what you're proposing here
On 15/04/17 17:05, Peter Bowen via dev-security-policy wrote:
On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy wrote:
On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:
On 13/04/17 14:23, Doug Beattie
On 15/08/17 13:29, Gervase Markham via dev-security-policy wrote:
Hi Rob,
On 26/07/17 11:21, Rob Stradling wrote:
https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing
Thanks for this. Any chance of saving me a bit of time by
cross-referencing
On 11/08/17 16:40, Nick Lamb via dev-security-policy wrote:
On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint)
On 16/08/17 22:57, alex.gaynor--- via dev-security-policy wrote:
On Wednesday, August 16, 2017 at 11:22:01 AM UTC-4, Rob Stradling wrote:
BTW, I've just asked Alex to look at adding the "CA Owner" field to the
misissued.com reports. :-)
It does this now :-)
Excellent. Thanks Alex. :-)
CAs,
Version 2.5 of the Mozilla Root Store Policy classifies
EKU=emailProtection intermediates as unconstrained when suitable name
constraints aren't present. As a result, such intermediates need to be
disclosed to the CCADB (although not until 15th January 2018 for those
intermediates
On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of
“www.intesasanpaolovita..biz” (note the two dots):
On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:
On 18/07/2017 16:19, Rob Stradling wrote:
On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni
Enhanced” which chains up to a Baltimore CyberTrust root,
On 20/07/17 15:24, Gervase Markham via dev-security-policy wrote:
On 12/07/17 21:18, Ben Wilson wrote:
For CAs with emailProtection and proper name constraints, where would such CAs
appear in https://crt.sh/mozilla-disclosures?
https://crt.sh/mozilla-disclosures#constrainedother? Or a new
On 26/07/17 11:44, Kurt Roeckx via dev-security-policy wrote:
On 2017-07-26 12:21, Rob Stradling wrote:
At Jonathan's suggestion, I've used the crt.sh DB to produce this
report of certs that have SAN:dNSName(s) that contain non-permitted
characters:
The report says "CN or dNSName". It's my
At Jonathan's suggestion, I've used the crt.sh DB to produce this report
of certs that have SAN:dNSName(s) that contain non-permitted characters:
https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing
I've only looked at certs for which there's a
On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)
Here's a report of all "double dot" certs known
L, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
Alex
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists
tment of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
Alex
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 18/07/17 16:57, Hanno Böck via dev-security-polic
r this
particular root.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozill
ozilla policy to avoid the debate over this
particular root.
Jeremy
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To:
https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.
This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new
certificates, that
On 05/07/17 18:08, Ryan Sleevi wrote:
On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote:
That is, the difference between, say:
"label": "Verisign/RSA Secure Server CA"
And
CKA_LABEL "Verisign/RSA Secure Server CA"
I would argue there isn't a meaningful difference for "human readability",
On 25/04/17 23:50, Ryan Sleevi via dev-security-policy wrote:
Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.
More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in
On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:
(Note: A few of the non-Symantec entries currently listed by
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
think. It looks like Kathleen has marked some roots as "Removed" on
C
On 27/04/17 11:56, Inigo Barreira wrote:
Good to know that our new certs are there :-)
Regarding StartCom, these are the new certs we´ve generated and will be used
to apply for inclusion in the Mozilla root program. Nothing to disclose at
the moment I guess. We´ve not been audited yet nor
In response to the many BR compliance issues [1] that have been reported
here this month, there's been renewed interest in certificate linting.
Various CAs have said that they're considering plugging one or more
certificate linters into their certificate issuance processes.
Some CAs, such as
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.
Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation
Yesterday I knocked together a script that: scrapes a URL (or a list of
URLs) for certificate files; then attempts to build a trust chain (using
https://crt.sh/gen-add-chain) for each certificate found; then submits
to some CT logs any trust chains that crt.sh hasn't previously seen.
I've
On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 13:07, Rob Stradling wrote:
It would seem that DigiCert noticed these 19 intermediates appear on
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep,
because they've all now been disclosed to the CCADB.
On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
Ryan,
If you look at the wide range of user agents accessing google.com today you'd
see many legacy applications and older versions of browsers and custom browsers
built from variants of the commercial browsers. By the time
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.
If you *rely* on AIA, then why not
On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:
在 2017年5月11日星期四 UTC+8下午5:58:00,Rob Stradling写道:
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh
On 16/05/17 16:11, Ryan Sleevi via dev-security-policy wrote:
On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
The important
On 11/05/17 18:05, Gervase Markham via dev-security-policy wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV
On 17/05/17 15:12, Gervase Markham via dev-security-policy wrote:
On 17/05/17 13:32, Rob Stradling wrote:
I've just added two columns to
https://crt.sh/mozilla-disclosures#undisclosed:
- "Earliest SCT".
- "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can
On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-17 14:40, Rob Stradling wrote:
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 19:05, Gervase Markham wrote:
On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username,
On 17/05/17 15:21, Gervase Markham via dev-security-policy wrote:
On 17/05/17 15:15, Rob Stradling wrote:
Shall I add the same two fields to
https://crt.sh/mozilla-disclosures#disclosureincomplete as well?
Yes, why not? :-)
Gerv
Done.
The "Listed Here Since" timestamps for the 24
On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but
On 08/06/17 14:15, Rob Stradling via dev-security-policy wrote:
On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL
Distribution Point URLs for each CA. The CDP URLs listed at
https
On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:
On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy wrote:
On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy
wrote:
On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certificate chains
*explicitly* here, not just say they saw it
[CC'ing rev...@digicert.com, as per
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028]
Annie,
"but these have been known about and deemed acceptable for years"
Known about by whom? Deemed acceptable by whom? Until
cert2.pem, ...> will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)
Alex
On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 16/06/17 20:11, A
On 23/06/17 14:49, Peter Bowen via dev-security-policy wrote:
On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-23 14:59, Rob Stradling wrote:
R
On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-23 14:59, Rob Stradling wrote:
Reasons:
- Some are only trusted by the old Adobe CDS program.
- Some are only trusted for Microsoft Kernel Mode Code Signing.
- Some are very old roots that are no longer trusted.
On 22/06/17 10:51, Rob Stradling via dev-security-policy wrote:
On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
Is this useful? if not, what key usage is interesting?
https://lock.cmpxchg8b.com/ServerOrAny.zip
Thanks for this, Tavis. I pointed my certscraper
(https
On 17/05/17 15:12, Gervase Markham wrote:
On 17/05/17 15:08, Rob Stradling wrote:
Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low
On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:
Hi Kathleen. I'm not quite sure how to interpret this part...
- I'm not sold on the idea of requiring Symantec to use third-party CAs to
perform validation/issuance on Symantec's behalf. The most serious concerns
that I have
On 16/05/17 19:53, Ryan Sleevi via dev-security-policy wrote:
What is the advantage of that, given that PKCS#7 involves
BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?
I don't think there is any notable advantage.
I asked the question because I thought it
On 06/06/17 22:26, Jakob Bohm wrote:
On 06/06/2017 22:08, Ryan Sleevi wrote:
Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it
easy to fire all the engineers, while keeping the sales team, and
outsourcing
On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote:
On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to
an RFC 1918 IP address. Surely that is a violation of the baseline
requirements.
On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
Hello, I was crawling the pkcs7 blobs in public pdf files and found some
intermediate certificates that don't appear in crt.sh.
I forwarded them to Rob, I don't know if this is useful to anyone else, but
they're available here.
On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
Is that what you meant, Peter?
You cannot set up a CNAME without configuring Salesforce, since they
would not
On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:
Hi Gerv,
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy wrote:
All,
I think it is time for us to change the domains that we are using for the CCADB
as follows.
Change the
On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote:
On 05/05/17 10:22, Rob Stradling wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an
On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:
I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of
On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote:
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
Alex, do you have the specific list of CAs at the time of your posting?
Yes, it was:
* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start
On 27/06/17 01:36, Ryan Sleevi via dev-security-policy wrote:
On Mon, Jun 26, 2017 at 9:50 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
A few root store operators at the recent CAB Forum meeting informally
discussed the idea of a common format for
On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:
On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:
Our CPS has now been updated.
Will you be ensuring that CAs like Gandi who are chaining back to your roots
also update their CPS?
Gandi are a managed
On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:
I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the
On 08/09/17 20:24, Andrew Ayer via dev-security-policy wrote:
The BRs state:
"Effective as of 8 September 2017, section 4.2 of a CA's Certificate
Policy and/or Certification Practice Statement (section 4.1 for CAs
still conforming to RFC 2527) SHALL state the CA's policy or practice
on
On 03/10/17 17:50, Kathleen Wilson via dev-security-policy wrote:
On Friday, September 29, 2017 at 1:29:26 PM UTC-7, Rob Stradling wrote:
Several CAs have issued intermediate CA certificates with duplicate
serial numbers. This is a clear violation of the serial number
uniqueness requirement of
On 04/10/17 13:18, Adriano Santoni via dev-security-policy wrote:
Are these "temporary unconstrained SubCA certificate"s publicly
trusted? That is, do they have valid signatures from your "Actalis
Authentication Root CA" (https://crt.sh/?caid=935) ?
If yes, can you confirm that you have
Hi Adriano.
It was pointed out to me that the doppelganger intermediate certificates
that Actalis issued to Unicredit (https://crt.sh/?id=47081615 and
https://crt.sh/?id=147626411) don't quite meet Mozilla's current
"technically constrained" criteria.
Since v2.3, the Mozilla Root Store
On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote:
The authors of the paper on the weak RSA keys generated by Infineon TPMs and
smart cards have published code in multiple languages / platforms that provide
for an efficient test for weakness by way of the Infineon TPM bug.
On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:
Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,
Hi Jakob. Today I ended up rewriting the ROCA fingerprint checker in C
(using OpenSSL BIGNUM calls) to get it working
Hi Hanno. Thanks for reporting this to us. We acknowledge the problem,
and as I mentioned at [1], we took steps to address it this morning.
We will follow-up with an incident report ASAP.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c3
On 11/09/17 15:18, Hanno Böck via
Hi Conny. Are you able to post those 2 certificates to some CT logs and
provide crt.sh links?
You've said that both certs have the same SHA-1 Fingerprint. Are you
sure about that?
On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote:
SwissSign has identified the following
On 11/09/17 15:30, Rob Stradling via dev-security-policy wrote:
Hi Hanno. Thanks for reporting this to us. We acknowledge the problem,
and as I mentioned at [1], we took steps to address it this morning.
We will follow-up with an incident report ASAP.
INCIDENT REPORT
We received two
Hi Adriano. Thanks for providing your incident report so promptly.
Some questions inline...
On 02/10/17 15:26, Adriano Santoni via dev-security-policy wrote:
6) Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
In the
Several CAs have issued intermediate CA certificates with duplicate
serial numbers. This is a clear violation of the serial number
uniqueness requirement of the BRs and RFC5280 4.1.2.2. Below is a list
of all those known to crt.sh that chain to at least 1 NSS built-in root:
Issuer:
Anyone who's using or planning to use these crt.sh APIs might like to
know that I've enhanced them to also run the ZLint certificate linter
(from https://github.com/zmap/zlint).
On 18/08/17 17:39, Rob Stradling via dev-security-policy wrote:
In response to the many BR compliance issues [1
/10/17 14:49, Rob Stradling via dev-security-policy wrote:
On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:
Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,
Hi Jakob. Today I ended up rewriting the ROCA fingerprint
On 24/11/17 12:25, Gervase Markham via dev-security-policy wrote:
On 24/11/17 11:37, Rob Stradling wrote:
When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the
On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:
If you look at where the HTTPS phishing certificates come from, they come
almost entirely from Let's Encrypt and Comodo.
This is perhaps the best argument in favor of distinguishing between CAs
that care about phishing and those
On 15/12/17 00:18, Matthew Hardeman via dev-security-policy wrote:
On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote:
Route hijacking your way to what would appear as a proper domain validation is
practical for even a modestly resourceful adversary. I suspect that
On 09/11/17 13:09, Rob Stradling via dev-security-policy wrote:
On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:
On Monday 6th November, we scanned the certificates that we'd issued
between 20th October and 5th November. 8 further server
authentication certificates were found
On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:
On Monday 6th November, we scanned the certificates that we'd issued
between 20th October and 5th November. 8 further server authentication
certificates were found, all for subdomains of the same registered
domain. We will get
I see all 7 of the certs identified in this thread in crt.sh:
Serial number: 4a907fbfc90eb043c50c9c8ace6305a1
SAN->dNSName: [www.]asik-portal.com
https://crt.sh/?id=13734110
Serial number: 8008c178d0d4cd3d79acc09f6ac132c
SAN->dNSName: *.Thameswater.co.uk
https://crt.sh/?id=249452540
Serial
Inspired by Paul Kehrer's research a few months ago, I've added a
continuous OCSP Monitoring feature to crt.sh:
https://crt.sh/ocsp-responders
This page shows the latest results of 3 OCSP checks (performed hourly)
against each CA / Responder URL that crt.sh has ever encountered:
1. a GET
On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote:
On 14/05/2018 10:42, Hanno Böck wrote:
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
On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote:
On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
Please see https://crt.sh/?id=353098570=cablint
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificate
On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote:
On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling
I'm currently running the check against all of the certs on the crt.sh
DB. I'll report back once this has completed.
Hi Rob,
Did your checks find anything else in the end?
[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations. Thanks!]
Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain
non-technically-constrained id-kp-emailProtection
+1
ISTM that Wayne is already doing an excellent job!
On 16/01/18 22:03, Kathleen Wilson via dev-security-policy wrote:
All,
I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I
are distributing the
Hanno, thanks for reporting this to us earlier today.
Mozilla, please consider adding https://crt.sh/?id=245397620 to OneCRL.
Thanks.
On 12/01/18 15:33, Hanno Böck via dev-security-policy wrote:
Hi,
Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port
On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:
On 08/02/18 13:47, Hanno Böck wrote:
Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.
In this case, the
On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote:
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
This incident makes me think that two changes should be made:
1) The Root Store Policy should explicitly ban forward and
about the Mozilla CA communication that said that CAs had until 15
April 2018?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29 PM
To: m
Hi Juan. Is there a particular technical reason why you feel the need
to include "all the certs chaining up to the roots" in your OCSP responses?
When an OCSP response is signed directly by the CA that issued the
corresponding certificate, the OCSP response does not need to contain
any
On 01/03/18 10:51, Ben Laurie via dev-security-policy wrote:
On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
wrote:
On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:
Please see https://crt.sh/?id=353098570=cablint
Note: This is the CT precertificate.
Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct. (error message: "OCSP response contains bad number of
On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote:
First of all, it's important to distinguish between the BR requirement, which is defined in terms
of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing
the "Not Before" value in this certificate is
On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:
On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
First of all, it's important to distinguish between the BR r
But even if you accept my premise there, then you have
We also asked Trustico to cease offering any tools to generate and/or
retain customer private keys. They have complied with this request and
have confirmed that they do not intend to offer any such tools again in
the future.
Trustico have also confirmed to us that they were not, and are not,
1 - 100 of 187 matches
Mail list logo