All, First, would like to say that we stoped to answer the questions, because at November was introduced another subject in that Public List, that was different about SERPRO SSL CA.
Bellow we answer all the outstanding questions: SERPRO SSLCA is subject to the Brazilian Public Key Infrastructure (ICP-Brasil) and the rules in force in ICP-Brasil. At the time of issuing these certificates, the SAN extension should contain other names in addition to the 'dnsName' and 'ipaddress' entries '. Once this requirement was understood, ICP-Brasil changed its certification policies and aligned them with the webtrust requirement. With this decision, the SERPRO SSL CA software was adjusted and the situation no longer occurred. After the completion of the correction (revocation of certificates), we also publish it in our bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c80 From that moment on, we started to include a weekly CACHECKER in our CA to eliminate other errors, which we still do till today. There were other notes by CACHECKER that we were requesting answers in bugzilla, among them, about an EV CERTIFICATE note that was issued with error. We do not issue EV CERTIFICATES only OV CERTIFICATES. https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c60 Then we received the response from Mozilla support pointing out that the error was in the updated CACHECKER: https://bugzilla.mozilla.org/show_bug.cgi?id=1677631#c65 Recently an error was pointed out(again) in EV certificates (which we do not issue) and in contact with Mozilla support, they verified that there is still an error in the CACHECKER that is showing false errors in our certificates. All can verify other comments in our bugzilla and the treatments that we have always given to everyone, that is, demonstration of responsibility with the issuance of certificates that are so vulnerable and that all CAs, which are part of these programs, must be attentive. All the notes already made here in this public list are just copied and pasted from a CACHECKER result, but do not demonstrate that they were verified, that they are certificates issued previously and that they have already been revoked, that is, there has already been a treatment. The motivation for joining the trusted roots program is the possibility of issuing certificates with international recognition that are also in line with Brazilian policies and practices, maintaining compliance with international standards and observing national needs. Currently SSL certificates are already issued at SERPRO SSL CA, not yet recognized, which imposes on end users to encounter messages from an unsafe site, leaving users with two possible approaches: include the CA as trusted or add a security exception; in both cases, we consider end-user security to be harmful practices. In this way, the inclusion of SERPRO SSL CA in the trusted root programs will increase the security of our end users. SERPRO is the largest public IT company in the world and provider digital solutions for the Brazilian state and the international market ( www.sepro.gov.br <https://brc-word-edit.officeapps.live.com/we/www.sepro.gov.br>). Regarding the use of a named-constraints to restrict .br domains only, we issue certificates to governments and also to national and international private entities that wish to have a certificate within the Brazilian public key infrastructure. Therefore, we do not consider the use of any named-constraint appropriate. Anyway, the criticisms were pointed out and were not evaluated as the CA has already responded promptly to all errors. The maturity of the CA and any one that is already part of a root program, was exactly as it was written earlier: mistakes everyone can make and the fact of quantity and lack of quality, all were mistakes already corrected. It was also mentioned that our CP or CPS was not read, which may not facilitate the purpose of our CA by someone here on this list. We would also like to add how we are a CA that holds the ISO/IEC 27001 and 27701 certification seals. All CAs that produce within SERPRO, except the one that issues an SSL certificate in accordance with BRSSL, have existed within the company for more than 20 years, that is, we are not a company wanting to experiment and only with the intention of selling certificates poor quality and non-compliant. Lucia Castelli Em quinta-feira, 1 de dezembro de 2022 às 14:38:45 UTC-3, [email protected] escreveu: > Dear Lucia et al, > > On Thursday, 17 November 2022 at 19:07:53 UTC+1 Lucia Castelli wrote: > >> Currently we only issue to *.br, due to our form of validation that >> involves the Registro.br, but *It has no restriction.* >> > > I understand from Brazilians I spoke to that SERPRO is a needed > certificate issuer for various Brazilian governmental services Brazilians > have to use, including tax revenue services. And right now they need to > manually install these CA certificates themselves. Is this correct? > > I notice that there has not been a follow-up from your side to the > questions and concerns raised by Kurt and others in over at least a week. > Given this is only a 6-week process for public discussion period, I am > worried about this lack of response from a CA. Especially given Ben's > initial email stating that "[..] a representative of SERPRO must promptly > respond directly in the discussion thread to all questions that are posted." > > While a glance at the crt.sh overview gives me an impression that your > process might have improved somewhat in recent times, I have strong doubts > about the suitability of SERPRO as a mature CA for default inclusion at > this time for a number of reasons: > > - There has, so far, not been any clarification given how the processes > have been adjusted accordingly to stop the issuing of certificates that are > not URLs, IP addresses, a certificate issued for a different country TLD > domain or other non-valid domains. > > - The various *.serpro domains issued in the past make me wonder just > how well internal and external CA responsibilities and processes have been > separated from one another, given that they are leaking onto the internet. > > - It is good to see that the various misissued certificates are revoked, > however for many it took many months before the problem was noticed and > acted upon. This again makes me wonder about both first and second line > processes/controls. It is fully understandable if a mistake is made. None > of us are perfect and we keep iterating on our processes to improve them. > However, whenever I deal with mistakes in line of my own work, whether they > are certificates or something else, I will look at the mistake and double > check recent work for similar of such mistakes. When I see a URL being > issued and then revoked a month later. And then spot another one, issued in > the same month, but being revoked 4 months later I can only wonder why no > automated process was kicked off to identify similar issues with your > certificates. Even if it was the rough equivalent of an "openssl x509 > -noout -subject -in <cert> | grep http" of all certificates. > > Jeroen Ruigrok van der Werven > > -- You received this message because you are subscribed to the Google Groups "public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/6ae7bfdb-517e-47f9-8fe6-66fead3c363cn%40ccadb.org.
