Richard's advice is worth following. m.d.s.policy is not about bugs in web
servers on the whole (and that's what you've got here most likely)
However, a quick Google suggests that "SSL record layer" is a term one popular
tool uses to describe any SSL or TLS Hello message that goes unanswered,
On Thursday, 23 February 2017 01:11:54 UTC, Richard Wang wrote:
> https://crt.sh/?id=65208905 for google.ligboy.org
Without wanting to jump on this pre-existing dogpile:
This specific example is illustrative of two important factors that should be
considered in examining the threat here:
On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote:
> With de facto use of AIA, there is no issuer installation on the server that
> could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
Much as I should like ubiquitous ambient Internet to be a
On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
Thanks for these responses Steve,
I believe that Symantec's decision to terminate the RA Partner programme was
On Thursday, 9 February 2017 03:08:14 UTC, Ryan Sleevi wrote:
> 19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur
> are the only Delegated Third Parties utilized by Symantec, across all
> Symantec operated CAs that are trusted by Mozilla products?
Maybe Ryan has better
On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote:
> - PKCS#7 chains are indeed not a requirement, but see point 1. It’s
> probably no coincidence that IIS supports it given awareness of the demands
> placed on enterprise IT admins.
I don't see how PKCS#7 offers any
On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote:
> Unfortunately, for these not-quite-web-server things (printers, routers
> etc.), automating use of the current ACME Let's encrypt protocol with
> or without hardcoding the Let's Encrypt URL is a non-starter for anyone
> using these
On Monday, 13 February 2017 15:15:47 UTC, Jürgen Brauckmann wrote:
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
> only 4 methods per Ballot 181?
Ballot 169 identified exactly 10 methods. Although this ballot passed
unanimously, meaning that both CA members
On Monday, 13 February 2017 16:18:46 UTC, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement the CA
> Issuers form of AIA for dynamic path discovery and educating server operators
> to get out of the practice of static chain installation on servers would
On Wednesday, 15 February 2017 22:02:50 UTC, Rob Stradling wrote:
> This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
> EKU and CN=hmrcset.trustis.com:
> It lacks the SAN extension, but that doesn't excuse it from the ban on
On Tuesday, 28 February 2017 12:29:30 UTC, Itzhak Daniel wrote:
> I also would like to have an official reply from GlobalSign saying that "on
> the date they issue the certificate the domain exists".
Doug/ GlobalSign has responded but I'll mention here that lists of recently
On Tuesday, 28 February 2017 16:00:47 UTC, Nick Lamb wrote:
> e.g. http://domaingraveyard.com/list/2016-05-10.txt
Typical, I posted that and then I checked from another browser and it now gives
an access error. Anyway, there are others of the same ilk out there, these
names (at least some of
On Monday, 27 February 2017 00:53:46 UTC, Itzhak Daniel wrote:
> How those lines are parsed? what happens when a client reaches a whitespace?
> Will this allow 'vietnamairlines.com' to use 'owa', 'mail' and 'autodiscover'
> in their internal infrastructure?
Because they're dnsNames a correctly
In order for Symantec to reveal anybody's private keys they'd first need to
have those keys, which is already, IIRC forbidden in the BRs. So even proof
that Symantec routinely had these keys is a big deal. The whole reason things
like CSR signing exist is that public CAs have no reason to know
On Friday, 24 March 2017 10:11:36 UTC, Gervase Markham wrote:
> I spoke about this with Doug at the CAB Forum meeting. The system which
> collects the data is not integrated with the system to which the domains
> are added. The validation specialist concerned, contrary to policy
> ("it's just a
Doesn't Chrome's behaviour already "penalise" plaintext HTTP? You can't build a
login form, or use shiny new features.
We aren't where we'd ideally be, everybody is agreed about that. That's not the
same thing as agreeing our direction of travel is wrong.
I am far from home reduced to using
This makes sense. How I imagine this in my head is if Mozilla were to come to
you asking about some particular certificate issued by GlobalSign you'd always
have records showing either that some sort of mechanical process validated the
Subject FQDNs, or that a specific human individual
On Tuesday, 4 April 2017 16:31:10 UTC+1, douglas...@gmail.com wrote:
> How this happened:
I have a question: These certificates appear to be not only forbidden by the
BRs but also technically unlikely to function as desired by the subscriber. Did
any customers report problems
On Monday, 10 April 2017 20:28:53 UTC+1, michael...@gmail.com wrote:
> A couple points of clarification please:
> 1) Mr. Byrne clarified his post to note that the flaws in the Symantec API
> would allow: retrieval of certificates that included private keys, not the
> private keys alone. Was
On Tuesday, 4 April 2017 04:18:41 UTC+1, Jakob Bohm wrote:
> So why does Mozilla want disclosure and not just a blanket X on a form
> stating that all SubCAs are adequately audited, follow BRs etc.?
Not speaking for Mozilla of course, but as a fan of disclosure provisions:
On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:
> I must be missing something still? The implication here is that a purchaser
> who is not yet part of the root program is permitted to take possession of
> the root cert private key and possibly the physical space, key personnel,
On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com wrote:
> I'm Tarah. I am the Principal Security Advocate and Senior Director of
> Engineering at Symantec Website Security (the certificate authority.
Regular readers of m.d.s.policy will not be surprised that the news
My understanding is that the QuickInvite system doesn't distinguish the
reseller from their customer in terms of access to the order.
It's not very clear from Symantec's documentation, and Tarah never got back to
me in the thread about it, but I think a reseller absolutely can wait for their
On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote:
> I propose this section be removed from the document.
I am not so sure the section ought to be removed. Wildcard DV is potentially
problematic. Historically we have seen problems that wouldn't have happened or
would be much
On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham wrote:
> This is all a bit inchoate :-) Can you give me any idea at all of what
> such a policy would look like? Requiring OV is not an option IMO.
Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be
On Saturday, 15 April 2017 13:59:18 UTC+1, Samuel Pinder wrote:
> Quite an interesting workaround to support older
> software, it's not exactly encouraging since SHA-1 collisions are now
> possible. I would expect that CloudFlare operate this solution on the
> condition that their customers are
Given the small number of certificates involved, it might make sense to just
convert them to text and mention them inline, or put them somewhere we can all
see them - if it's inconvenient to put them into the CT logs.
I think this situation will be useful as evidence of the value of
On Saturday, 22 April 2017 02:24:50 UTC+1, Matt Palmer wrote:
> Can you remind me (and the list) what specific instances you're referring
I was thinking of things like the GoDaddy incident reported in January where
they had mistakenly been accepting HTTP 404s to validate a domain or the
On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote:
> I believe the point was to check the prospective contents of the
> TBSCertificate *before* CT logging (noting that Ryan Sleevi has been
> violently insisting that failing to do that shall be punished as
> harshly as actual misissuance)
On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote:
> Are you saying that there are one or more clients that require DigiCert to
> support Teletext strings?
Can we stop saying Teletext? The X500 series standards are talking about
Teletex. One letter shorter.
Teletext was invented by the
On Friday, 3 March 2017 07:49:28 UTC, Ryan Sleevi wrote:
> It is not acceptable. It's explicitly prohibited multiple ways to allow
> more than 24 hours when such situations are brought to the CAs' attention.
I'm sympathetic to the idea, here and in all cases where we have no reason to
Further to Ryan's reply, we can once again take lessons from the real world
Ordinarily notice in law can be given by sending a letter and waiting a few
days. There is no obligation to prove the letter was delivered, let alone read
and comprehended, only that it was sent and that it was
Other contributors have, I think, summed up the pros and cons of the two ways
forward on the specific date very effectively.
So I will expend my effort instead on pressing for Mozilla to handle final
distrust of the old Symantec CA roots in its usual fashion and explicitly _not_
do as Symantec
1. It is well established that logging pre-certs constitutes "issuance" for
purposes of policy compliance. If you wouldn't issue it, don't log it. Not
difficult. And this isn't new.
2. When a new path comes into existence in the Web PKI you don't need to
explicitly "use" it as a CA, the
On top of what Ryan has written, I want to specifically praise the approach of
actually checking a sample of certificates as PKIoverheid describes.
I think done well this can be a very affordable yet timely and effective way to
detect problems in a particular issuance pipeline or with a
On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote:
> Could you expand on this? It's not obvious what you mean.
I guess I was unclear. My concern was that one obvious way to approach this is
to set things up so that after the certificate is signed, Boulder runs cablint,
and if it
On Thursday, 10 August 2017 16:20:56 UTC+1, Jonathan Rudenberg wrote:
- Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure
Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”,
(which are not in this list) appear to issue certificates with serial
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) for these issues so they don't need to be
On Sunday, 13 August 2017 04:04:45 UTC+1, Eric Mill wrote:
> While not every issuing CA may take security seriously enough to employ
> engineers on staff who can research, author and deploy a production code
> fix in a 24 hour period, every issuing CA should be able to muster the
> strength to
One good thing we should be able to hope for from a change in ownership even if
the personnel and equipment are the same or a great deal in common: improved
management oversight. In my view the most worrying underlying problem at
Symantec was the inadequate oversight. Senior management at the
On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com wrote:
> certificates contain the issue. Three (3) of these are real certificates;
> however, one has expired. We have revoked the other two certificates. The
> remaining two (2) are pre-certificates.
To clear this up for anybody who
On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson wrote:
> Thank you for bringing this to our attention. We have contacted Intesa
> Sanpaolo regarding this error and have asked them to correct it as soon as
"Correcting" the error is surely the smaller of the two tasks ahead.
On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>
> So at least some of them have been notified more than 3 months ago, and
> a bug was filed a month later. I think you already gave them too much
> time to at least respond to it, and suggest that you sent a new email
On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm wrote:
> 1. I believe (though others may know better) that the high general
>requirements for the security of CA systems also apply to the
>systems performing the validation procedures in question.
Yes, however I don't think Matthew's
On Tuesday, 18 July 2017 20:29:50 UTC+1, Jeremy Rowley wrote:
> Some of these certs are really old. Is there a reason people were using
> double dot names? Are they all mistakes in the certificate request or is
> there some logic behind them?
Unless I see good evidence to the contrary I will
On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote:
> As easily as that, one could definitely get a certificate issued without
> breaking most of the internet, without leaving much of a trace, and without
> failing domain validation.
One trace this would leave, if done using Let's
On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss wrote:
> This CA also issued a recent certificate for the unqualified dNSName
> 'webinterfacestrong': https://crt.sh/?id=177606495
Another name that it shouldn't be possible to issue for, but this time one
which can actually exist in local
On Tuesday, 25 July 2017 21:29:06 UTC+1, Rick Andrews wrote:
> The details of this process would probably be best served in a separate
> thread. Essentially, such a process would involve a quick assessment by the
> community on the context and merits of the request by the customer
You want us
On Monday, 3 July 2017 23:05:53 UTC+1, Jeremy Rowley wrote:
> And it's hardly fair to deride my lack of understanding on what transitive
> trust entails in the digital certificate space considering it's outside of
> the usual trust paths, not defined in the standard RFCs, and not the same as
On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley wrote:
> Link please to a formal definition? As your email alleges a policy violation
> by one a cross-signed CAs, we take the investigation and response very
> seriously. I'd like to know the basis for the definition before formulating
On Tuesday, 4 July 2017 10:50:43 UTC+1, Jeremy Rowley wrote:
> I'm an idiot. The discussion wasn't meant to be a red herring. Just a
> momentary lapse in intelligence...
> It really looks like this from a validation perspective, right? EE ->
> Self-signed -> Issuing CA (as it has the same
On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei wrote:
> 1. the CN of two cerificates are same. So it is not necessary to issue two
> certificates in just 2 minutes.
I think the most likely explanation is the difference in signature algorithm,
but it is also not uncommon for subscribers to
On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson wrote:
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
Is there any progress on this? To be honest I was more meaning that
On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote:
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.
Even if I had no
On Sunday, 6 August 2017 14:10:36 UTC+1, firstname.lastname@example.org wrote:
> - Using non-IDNA encoded values in the CN, but (correctly!) IDNA encoding the
At least one popular implementation of TLS in a non-browser client (the Python
If it's your belief that the Python code actually does work for IDN SANs I
think you're going to need to do better than just asserting that it's "simply"
so in the face of subject experts saying it's broken.
On Tuesday, 2 May 2017 14:52:52 UTC+1, Gervase Markham wrote:
> Group participants may be interested in David Keeler's analysis of why
> Firefox seemed to be seeing cert pinning mismatches for Mozilla properties:
Thanks for your notice Kathleen.
One thought: Very often several CAs ask for more time to complete the Mozilla
survey, either explicitly, or implicitly by just not filling it out in a timely
fashion and saying they're very busy and will do it "soon" if they're asked.
If you believe there are,
Cory, from your point of view is there interest in being able to tell Requests
"I want the no-compromises trust store" and accept a reduced compatibility in
exchange for knowing that you're a little safer ?
Right now, as a programmer I have three choices with Requests:
On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin wrote:
> We think it is critically important to distinguish potential removal of
> support for current roots in Firefox versus across NSS. Limiting Firefox
> trust to a subset of roots while leaving NSS unchanged would avoid
On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote:
> The right balance is probably revoking when misuse is shown.
Plus education. Robin has stated that there _are_ suitable CA products for this
use case in existence today, but if I didn't know it stands to reason that at
On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman wrote:
> From a perspective of risk to the broader web PKI, it would appear that a
> properly name constrained intermediate with (for example) only the Server
> and Client TLS authentication ekus with name constraints limited to
On Saturday, 20 May 2017 15:49:44 UTC+1, Michael Casadevall wrote:
> Sanity check here, but I thought that OCSP-CT-Stapling required SCTs to
> be created at the time of issuance. Not sure if there's a way to
> backdate this requirement. If this is only intended for the new roots
> then just a
On Thursday, 18 May 2017 04:23:17 UTC+1, Aaron Wu wrote:
> - DV SSL Certificates - the domain name registrar must list the applicant as
> part of the WHOIS record; or effective control of the domain shall be
> demonstrated by the applicant or communication satisfying BR 188.8.131.52 shall be
I think a broad definition is appropriate here. Mozilla is not obliged to do
anything at all, much less anything drastic if it is discovered that
mis-issuance has occurred. At most we might think it time to re-evaluate this
Fools are endlessly inventive so a too narrow definition runs
On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi wrote:
> Standards defining organization.
More usually a Standards _Development_ Organization. I wouldn't usually feel
the need to offer this correction but in this context we care a good deal about
the fact that SDOs are where the actual
On Monday, 1 May 2017 22:02:58 UTC+1, Lee wrote:
> Maybe it's because I've worked with some incredibly bad auditors, but
> the way I read the proposal, doing anything other than one of those
> exact 10 methods is risking an audit failure.
> How would you word the policy to make it clear that
I'm struggling to get my head around what you're asking for. I think you're
seriously asking if there's a way to skip all the actual security of DNSSEC and
get a secure answer anyway?
No. The answer is "No". If you're comfortable with answers that might be lies,
you can skip DNSSEC entirely.
Gerv, rather than start by digging into the specific technical details, let me
ask a high level question.
Suppose I have deployed DNSSEC for my domain tlrmx.org and I have a CAA record
saying to only permit the non-existent Gotham Certificates gotham.example to
You say you don't want
On Thursday, 14 September 2017 16:00:35 UTC+1, Inigo Barreira wrote:
> Well, finally this is a business and I don´t think none on this list is
> working for free. At the end everyone has his/her salary, etc. But that was
> not the main reason because getting included in the root programs takes
On Friday, 22 September 2017 05:01:03 UTC+1, Peter Bowen wrote:
> I realize this is somewhat more complex than what you, Ryan, or Jeremy
> proposed, but it the only way I see root pins working across both
> "old" and "new" trust stores.
I would suggest that a better way to spend the remaining
On Monday, 16 October 2017 23:15:51 UTC+1, Jakob Bohm wrote:
> They have also obfuscated their test by providing bitmasks as decimal
> bigints instead of using hexadecimal or any other format that makes the
> bitmasks human readable.
The essential fingerprinting trick comes down to this (I had
I have briefly inspected this BR Self Assessment document. Nothing terrifying
leaped out at me that would lead me to ask that Mozilla deny the renewal,
however I did find things worth mentioning here.
The only listed 184.108.40.206 method is 220.127.116.11.5, Domain Authorization Document.
Thanks for writing this incident report.
The latter of the two certificates was issued after popular web browsers had
ceased accepting SHA-1 as far as I understand it. As a result it seems likely
that it would not have functioned as expected if a customer deployed it on a
Web server. You
On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira wrote:
> Futhermore, according to the logs, at the time of checking for a CAA record,
> there was none. The lookup was succesful and hence allowed the issuance.
Given that this contradicts the facts alleged in Quirin's tests and the
On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the
> sentence "the domain's zone does not have a DNSSEC validation chain
I think that instead Ryan H is suggesting that (some) CAs are taking advantage
of multiple geographically distinct nodes to run the tests from one of the
Blessed Methods against an applicant's systems from several places on the
Internet at once. This mitigates against attacks that are able to
Actually previous SHA-1 certs might be one of the least objectionable
non-compliances assuming that nobody expects Firefox, or other clients in the
Web PKI to actually trust these certs, because the difference in signature
algorithm contains the risk nicely.
Bad guys who have speculatively
I'll speak up for transparency again. In terms of policy the most vital thing
is that a CA tells us about such certs during application. One way to do that
would be to CT log them, but especially for small sets there might be other
sensible ways. If we can't be shown the certs in question (or
Kurt, I think both the past experiences of m.d.s.policy with incidents that
went undetected by auditors, and my own personal experience (not as part of the
Web PKI) with professional audit firms is that they're not strong on the sort
of technical requirements that we've seen here.
If the rule
On Wednesday, 4 October 2017 13:34:17 UTC+1, Adriano Santoni wrote:
> I think I have addressed this in my reply to Rob Stradling a few minutes
> In short: no, the "temporary unconstrained subCA" does never exist as a
> signed document, only the final (constrained) subCA is
On Wednesday, 18 October 2017 10:15:03 UTC+1, Rob Stradling wrote:
> I've completed a full scan of the crt.sh DB, which found 171 certs with
> ROCA fingerprints.
> The list is at https://misissued.com/batch/28/
> Many of these are Qualified/EUTL certs rather than anything to do with
On Fri, 24 Nov 2017 12:25:40 +
Gervase Markham via dev-security-policy
> Validate example.com -> add "www.example.com": seems fine to me, and a
> reasonable accommodation to a common customer desire.
> Validate www.example.com -> add
On Tue, 28 Nov 2017 04:26:30 +0100
Jakob Bohm via dev-security-policy
> Nick Lamb, in the message I replied to, clearly suggested as much, and
> provided a contrived scenario to "prove" that point.
That's true, and I apologise if the effect was to
On Wed, 29 Nov 2017 22:37:08 +
Ben Laurie via dev-security-policy
> Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
> chain of responsibility for keys, and that is relatively easy to
> build on.
For DNSSEC a CA could (and
On Thu, 14 Dec 2017 16:33:29 -0800 (PST)
Matthew Hardeman via dev-security-policy
> That attack was by hacking the target's domain registrar account.
> Others have done that as well, including against a Brazilian bank.
> The right attacker would
On Wed, 13 Dec 2017 12:29:40 +0100
Jakob Bohm via dev-security-policy
> What is *programmatically* enforced is too little for human safety.
> believing that computers can replace human judgement is a big mistake.
> Most of the world knows this.
4.1 Further to Gerv's question in the bug, I see that Digicert have not
actually enumerated the set of issued certificates which are affected. Are you
confident that if it became necessary you can do this? I recommend doing this
and reporting the count even if not asked to actually list all the
On Tuesday, 14 November 2017 16:31:34 UTC, Kathleen Wilson wrote:
> Based on information from folks that are monitoring their NS Records, we
> believe that the .tg Registry problems were fixed on November 1, and
> have remained fixed since then.
> I have not looked into how Registries are
My understanding is that postal codes written in this form are understood (even
if not always specifically permitted) by many postal authorities and so this
deviation would not be likely to impact deliverability of a snail mail letter
sent (for whatever reason) to the address shown in the
On Sat, 9 Dec 2017 18:20:56 +
Tim Hollebeek via dev-security-policy
> First, third parties who are *not* CAs can run key generation and
> escrow services, and then the third party service can apply for a
> certificate for the key, and deliver the
On Sat, 9 Dec 2017 09:51:59 +0100
Hanno Böck via dev-security-policy
> On Fri, 8 Dec 2017 16:43:48 -0700
> Wayne Thayer via dev-security-policy
> > The root CA is ultimately responsible for
On Mon, 11 Dec 2017 19:08:43 -0500
Adam Caudill via dev-security-policy
> I can say from my own experience, in some states in the US, it's a
> trivial matter to create a company online, with no validation of
> identity or other information. It takes
As a lowly relying party, I have to say I'd expect better here.In particular, if example.com says their DNSSEC signed CAA forbade Let's Encrypt from issuing, and Let's Encrypt says otherwise, I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The
On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published
I will summarise briefly my understanding of this report in case it is
wrong, if so please correct me, I apologise, and the rest of the email
is probably of no further importance:
GoDaddy integrated a linter (checking the certificates for sense) in
November 2017, and in February this
On Fri, 29 Dec 2017 07:24:31 +0100
Jakob Bohm via dev-security-policy
> 3. Or would the elimination in #2 reduce the entropy of such serial
>numbers to slightly less than 64 bits (since there are less than
> 2**64 allowed values for all but the
On Wed, 10 Jan 2018 15:10:41 +0100
Patrick Figel via dev-security-policy
> A user on Hacker News brought up the possibility that the fairly
> popular DirectAdmin control panel might also demonstrate the
> problematic behaviour mentioned in your
On Mon, 15 Jan 2018 18:18:10 +
Doug Beattie via dev-security-policy
> - Total number of active OneClick customers: < 10
What constitutes a OneClick customer in this sense?
The focus of concern for tls-sni-01 was service providers who
On Fri, 16 Feb 2018 11:28:41 +
Arkadiusz Ławniczak via dev-security-policy
> The issue was caused by incorrect calculation of the SHA1
> fingerprint of public key. Public keys hashes stored in Certum's
> database was calculated from the
1 - 100 of 154 matches
Mail list logo