We do not intend to revoke the end-user certificates.
We consider this to be a compliance issue for the CA certificates only. The CAs
(i.e. the private keys) and end-user certificates issued from the CAs are not
affected.
Regards
Mads
-Original Message-
From: dev-security-policy On
Hi
This is an incident report for two intermediate certificates issued by Buypass
in December 2016 noncompliant with BR 7.1.
===How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
We are aware that Buypass is on the list of CAs that have been noncompliant
with BR 7.1. We will send an Incident Report within the next few days.
Regards
Mads
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Hi
One of the non-technically-constrained intermediate certificates on the list
[2] below is issued by Buypass and this was revoked today - see
https://crt.sh/?id=157337628.
This was done to be compliant with Section 5.3.1 of Mozilla Root Store Policy v
2.5 [1] - as specified in Action 1 of
Hi Wayne
Buypass has used the TLS-SNI-01 method in our ACME Pilot running since last
summer. We have issued some certificates using this method - less than 60
certificates are still active and not revoked, most of them are issued to
internal users and systems.
We stopped using this method
Hi
Late last week we discovered three certificates issued from Buypass with an
error in the subject:PostalCode for one dutch company. One of these
certificates is available at https://crt.sh/?id=212774960
The postalcode should have been '3707BK' as registered in the European Business
Register
Hi
Buypass received the problem report at 2017-09-12 00:06 and started
investigating early this morning.
After investigating what happened we identified an error in our system solution
when we have a CAA RR lookup failure. In this case, the DNS CAA RR lookup timed
out several times and we
7 matches
Mail list logo