On 28/11/2017 15:53, Nick Lamb wrote:
On Tue, 28 Nov 2017 04:26:30 +0100
Jakob Bohm via dev-security-policy
wrote:
Nick Lamb, in the message I replied to, clearly suggested as much, and
provided a contrived scenario to "prove" that point.
That's true,
On Tue, 28 Nov 2017 04:26:30 +0100
Jakob Bohm via dev-security-policy
wrote:
> 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 28/11/2017 04:16, Ryan Sleevi wrote:
On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 27/11/2017 19:37, Nick Lamb wrote:
On Fri, 24 Nov 2017 12:25:40 +
Gervase Markham via dev-security-policy
On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 27/11/2017 19:37, Nick Lamb wrote:
>
>> On Fri, 24 Nov 2017 12:25:40 +
>> Gervase Markham via dev-security-policy
>> wrote:
>>
>>
On 28/11/2017 02:29, Jakob Bohm wrote:
On 27/11/2017 19:37, Nick Lamb wrote:
On Fri, 24 Nov 2017 12:25:40 +
Gervase Markham via dev-security-policy
wrote:
...
While your scenario below sounds compelling, it is very much a contrived
scenario of the
The thing is, extraneous names on a certificate present a subtle
security flaw, even if control over those names was validated properly
I agree, if the user is not fully aware of these addition, it can add
subtle security flaw such as "virtual host confusion attacks" (
On Fri, 24 Nov 2017 12:25:40 +
Gervase Markham via dev-security-policy
wrote:
> 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 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 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 "base domain"
> (e.g., example.com). (Similarly, if the
Dear Corey,
Dear Jeremy,
thank you for your responses! I had seen a certificate with this pattern, and
confirmed by your answers have done a more complete scan.
I found 5 certificates with that pattern that had CAA records set at issuance
time (approximated by “not valid before” and SCT)
On Wednesday, November 15, 2017 at 8:11:18 AM UTC-5, Quirin Scheitle wrote:
> Hi all,
>
> I have a question regarding processing of CAA records for “wildcard
> certificates”.
>
> Let’s assume the following CSR:
>
> X509v3 Subject Alternative Name:
>DNS: *.example.com
>
Hi all,
I have a question regarding processing of CAA records for “wildcard
certificates”.
Let’s assume the following CSR:
X509v3 Subject Alternative Name:
DNS: *.example.com
DNS: example.com
Per BR, every SAN DNS name must be checked separately.
Now, my
12 matches
Mail list logo