Re: A-Trust Root Renewal Request
Dear Mr Christoph Klein, >>* V Clause (X): We analyzed this problem and found an issue, where the >>variable wasn't transfered into the final certificate. This bug has been >>around since our first issued EV certificate and wasn't noticed until now. >>The problem is fixed, new certificates will replace the x with the proper >>letter. >>>Given that every EV certificate you issued had this error, and you have been issuing EV certificates since at least 2013 (from your old root), how was this error not detected by the self-audit you are required to perform of 'a randomly selected sample of at least three percent of the EV Certificates'? This text is not permitted since EV guidelines version 1.3, published in 2010. Please, read the "Guidelines For The Issuance And Management Of Extended Validation Certificates" (https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf) Section 9.2.4: Certificate field: subject:businessCategory (OID: 2.5.4.15) Required/Optional: Required Contents: This field MUST contain one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity" depending upon whether the Subject qualifies under the terms of Section 8.5.2, 8.5.3, 8.5.4 or 8.5.5 of these Guidelines, respectively. Best, J ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A-Trust Root Renewal Request
Thanks Mr Erwann Abalea to bring this to our (my) attention. As the A-trust EV audit report do not include any CA in scope and only states "for its Certification Authority (CA) operations at Vienna"... Should we consider this audit includes all roots and subordinates? I can not find any EV certificate issued by a-sign-SSL-EV-05 during the audit period, but I am afraid this is a common practice due all certificates contains the same businessCategory text and because I found EV certificates issued by "a-sign-SSL-EV-03" from other A-trust hierarchy (Sorry for including other A-trust hierarchy in this public discussion but it's just to illustrate my comment) that also includes the same businessCategory text issued during the audit period report. Examples: https://www.a-trust.at/DesktopModules/LdapSuche/Download.aspx?type=downloadCert=1468071 https://www.a-trust.at/DesktopModules/LdapSuche/Download.aspx?type=downloadCert=1352665 As I comment in last post, the permitted text on the businessCategory changed on EV Guidelines 1.3 (2010). How auditors could not detect this basic issue? And A-trust, why your internal procedures fail to align the EV profile for 5 years? Best J El martes, 9 de febrero de 2016, 13:24:29 (UTC+1), Erwann Abalea escribió: > Bonjour, > > Le mardi 9 février 2016 10:47:16 UTC+1, Jesus F a écrit : > > Dear all, > > > > As A-Trust request EV treatment, I checked the EV issued certificates from > > a-sign-SSL-EV-05 subordinate in ctr.sh > > (https://crt.sh/?Identity=%25=6096) > > > > ALL of them states in businessCategory the following text "V1.0, Clause > > 5.(X)". This text is similar to what permitted by EV guidelines version 1.2 > > and prior, although "X" should have been "b", "c", "d" or "e" depending > > upon whether the Subject qualifies in the permitted categories. This text > > is not permitted since EV guidelines version 1.3 published in 2010. > > > > As the EV audit conducted by E states A-trust is in compliance with > > "WebTrust Principles and Criteria for Certification Authorities - Extended > > Validation SSL - Version 1.4.5" that is based on CA/Browser Forum > > Guidelines for the Issuance and Management of Extended Validation SSL > > Certificates - Version 1.4.5 and it's obvious that the auditor failed to > > detect this very basic issue, can we, the Mozilla Community, be reasonably > > assured of any of the auditor's necessary checks? > > > > In addition there are several more issues in this certificates: > > > > - rfc822Name in SAN (https://crt.sh/?id=8889537=cablint, > > https://crt.sh/?id=8889537=cablint) > > - FATAL: ASN.1 Error in EmailAddress > > (https://crt.sh/?id=12491213=cablint, > > https://crt.sh/?id=9410992=cablint) > > - This cert has the following errors: Cert without subject alternative > > names extension, Cert of 1024 bits (https://crt.sh/?id=8935972=cablint) > > Without saying that the audit was perfect, but all the presented evidences > here have been produced after the audit was performed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Dear Mozilla community, Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding the audits accepted by Mozilla and may someone can help me. The BR audit was conducted according to the WebTrust forCertification Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's a point-of-time (as of April 26, 2015). Although this audit criteria is accepted according to the Mozilla CA Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded by Webtrust SSL Baseline with Network Security version 2.0 (effective for audit periods starting on or after July 1, 2014). Webtrust audit criteria states that "The point-in-time readiness assessment shall be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and shall be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. (See SSL Baseline Requirements Section 17.4)". Should Mozilla expect a complete audit 90 days after the point-in-time BR audit report or after the first certificate (I don't know when was issued)? In addition and regarding the OCSP Responder certificate with Serial Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 years. According the RFC 6960 "A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." Which is the maximum acceptable lifetime for this type of certificates that contains the id-pkix-ocsp-nocheck extension? PS: Now I cannot test the OCSP due a server error "Code=503,Reason=Service Unavailable" Best ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign Root Renewal Request
Dear WoSign and Mozilla community, The CRL downloaded on june 29th from http://crls8.wosign.com/ca8-ssl4.crl (CRL distribution point in https://root5evtest.wosign.com certificate) has a CRL number of 00. It also applies for the CRL downloaded on the same date from http://crls6.wosign.com/ca6-ssl4.crl (CRL distribution point in https://root4evtest.wosign.com/) which has a CRL number of 00. According to the Webtrust for CA 2.0 CAs include a monotonically increasing sequence number for each CRL issued by that CA. (See section 6.8 control 7). Also see section 5.2.3 of the RFC5280 (The CRL number is a non-critical CRL extension that conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer). As WoSign has the Webtrust for CA Seal, could WoSign please explain how this control is fullfilled? Thanks in advance. Best regards, J El jueves, 4 de junio de 2015, 19:56:16 (UTC+2), Kathleen Wilson escribió: WoSign has applied to include the Certification Authority of WoSign G2 and CA WoSign ECC Root root certificates, turn on all three trust bits for both roots, and enable EV treatment for both roots. WoSign's previous root certificates were included via Bugzilla Bug #851435. WoSign issues certificates to the general public in China. Their SSL certificates are deployed in top 10 eCommerce websites in China; for bank, telecom, enterprise etc. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156175 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8606022 Noteworthy points: * Documents are provided in Chinese, and the CPS has been translated into English. Document Repository (Chinese): http://www.wosign.com/policy/cps.htm CPS (English): http://www.wosign.com/policy/cps_e.htm * CA Hierarchy for the Certification Authority of WoSign G2 root: The plan is to have 10 internally-operated subCAs for 3 types of certificates: SSL Certificate, Code Signing Certificate and Client Certificate. 1. WoSign Class 4/3/2/1 EV/OV/IV/DV SSL CA G2 2. WoSign Class 4/3/2 EV/OV/IV Code Signing CA G2 3. WoSign Class 3/2/1 Client CA G2 Currently, one of the subCAs has been issued: WoSign Class 4 EV SSL CA G2 * CA Hierarchy for the CA WoSign ECC Root root: The plan is to have 10 internally-operated subCAs for 3 types of certificates: SSL Certificate, Code Signing Certificate and Client Certificate. 1. WoSign Class 4/3/2/1 EV/OV/IV/DV ECC SSL CA 2. WoSign Class 4/3/2 EV/OV/IV ECC Code Signing CA 3. WoSign Class 3/2/1 ECC Client CA Currently, one of the subCAs has been issued: WoSign Class 4 EV ECC SSL CA * This request is to turn on all three trust bits for both roots, and to enable EV treatment for both roots. ** CPS section 3.2.2.1 -- Class 1 *** Email accounts are validated by sending an electronic mail message with a verification code to the requested email account. The subscriber has to return and submit the verification code as prove of ownership of the email account within a limited period sufficient enough to receive an electronic mail message. *** Fully qualified domain names, typically www.domain.com or domain.com are validated by sending an electronic mail message with a verification code to one of the following administrative electronic mail accounts: webmas...@domain.com, hostmas...@domain.com, postmas...@domain.com, ad...@domain.com, administra...@domain.com The subscriber has to return and submit the verification code as prove of ownership of the domain name within a limited period sufficient enough to receive an electronic mail message. Additionally the existence of the domain name is verified by checking the WHOIS records provided by the domain name registrar. If the WHOIS data contain an administrative email addresses, they may be offered as additional choices to the above mentioned electronic mail accounts. If subscriber can't receive email from the above 6 email account, he/she can choose to do the website control validation that the subscriber must upload a website control validation code file to the website root directory to finish the website control validation. WoSign performs additional sanity and fraud prevention checks as outlined in section 3.1.6. Wild card domain names like *.domain.com are not issued in the Class 1 level. WoSign SSL certificate support IDN domain in Chinese and other languages, so Wosign makes a reasonable check for similar sounding and looking names to prevent possible abuse which is applied also to non-IDN names such as PAYPA1.COM, MICR0S0FT.COM etc. and all IDN domain also need the domain ownership verification by system same as normal non-IDN domains ** CPS section 3.2.2.2 - Class 2 The verification process of personal identities of subscribers are performed
Re: WoSign Root Renewal Request
Dear All, Thanks Peter for your clarification but I think I haven't explained myself properly. My concern is not about that both CRL has the same CRL number (due they are from different hierarchies). My concern is about how the CRL number is treated by WoSign and how this number is increased. As the WoSign renewal request was posted on june 4th, WoSign had published previous CRLs (as per BR has to publish CRL at least every 7 days). If the actual CRL has a CRL number of 0, which CRL number has the previous ones (-1, -2)? and which CRL number will have the next CRL? I understood that each CRL has to have a monotonically increasing CRL number (for example 1 the first one, 2 the next one and so on). May I be wrong? (I would appreciate an explanation if I am wrong.) Thanks in advance Best Regards, J El jueves, 4 de junio de 2015, 19:56:16 (UTC+2), Kathleen Wilson escribió: WoSign has applied to include the Certification Authority of WoSign G2 and CA WoSign ECC Root root certificates, turn on all three trust bits for both roots, and enable EV treatment for both roots. WoSign's previous root certificates were included via Bugzilla Bug #851435. WoSign issues certificates to the general public in China. Their SSL certificates are deployed in top 10 eCommerce websites in China; for bank, telecom, enterprise etc. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156175 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8606022 Noteworthy points: * Documents are provided in Chinese, and the CPS has been translated into English. Document Repository (Chinese): http://www.wosign.com/policy/cps.htm CPS (English): http://www.wosign.com/policy/cps_e.htm * CA Hierarchy for the Certification Authority of WoSign G2 root: The plan is to have 10 internally-operated subCAs for 3 types of certificates: SSL Certificate, Code Signing Certificate and Client Certificate. 1. WoSign Class 4/3/2/1 EV/OV/IV/DV SSL CA G2 2. WoSign Class 4/3/2 EV/OV/IV Code Signing CA G2 3. WoSign Class 3/2/1 Client CA G2 Currently, one of the subCAs has been issued: WoSign Class 4 EV SSL CA G2 * CA Hierarchy for the CA WoSign ECC Root root: The plan is to have 10 internally-operated subCAs for 3 types of certificates: SSL Certificate, Code Signing Certificate and Client Certificate. 1. WoSign Class 4/3/2/1 EV/OV/IV/DV ECC SSL CA 2. WoSign Class 4/3/2 EV/OV/IV ECC Code Signing CA 3. WoSign Class 3/2/1 ECC Client CA Currently, one of the subCAs has been issued: WoSign Class 4 EV ECC SSL CA * This request is to turn on all three trust bits for both roots, and to enable EV treatment for both roots. ** CPS section 3.2.2.1 -- Class 1 *** Email accounts are validated by sending an electronic mail message with a verification code to the requested email account. The subscriber has to return and submit the verification code as prove of ownership of the email account within a limited period sufficient enough to receive an electronic mail message. *** Fully qualified domain names, typically www.domain.com or domain.com are validated by sending an electronic mail message with a verification code to one of the following administrative electronic mail accounts: webmas...@domain.com, hostmas...@domain.com, postmas...@domain.com, ad...@domain.com, administra...@domain.com The subscriber has to return and submit the verification code as prove of ownership of the domain name within a limited period sufficient enough to receive an electronic mail message. Additionally the existence of the domain name is verified by checking the WHOIS records provided by the domain name registrar. If the WHOIS data contain an administrative email addresses, they may be offered as additional choices to the above mentioned electronic mail accounts. If subscriber can't receive email from the above 6 email account, he/she can choose to do the website control validation that the subscriber must upload a website control validation code file to the website root directory to finish the website control validation. WoSign performs additional sanity and fraud prevention checks as outlined in section 3.1.6. Wild card domain names like *.domain.com are not issued in the Class 1 level. WoSign SSL certificate support IDN domain in Chinese and other languages, so Wosign makes a reasonable check for similar sounding and looking names to prevent possible abuse which is applied also to non-IDN names such as PAYPA1.COM, MICR0S0FT.COM etc. and all IDN domain also need the domain ownership verification by system same as normal non-IDN domains ** CPS section 3.2.2.2 - Class 2 The verification process of personal identities of subscribers are performed manually. The WoSign CA validates without any
Re: TurkTrust Root Renewal Request
Hi Volkan,
Look at RFC2560/6960 section A.1, describing the format of a request sent over
HTTP:
An OCSP request using the GET method is constructed as follows:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
That is, some characters from the base64 representation of the request are
transformed:
/ is transformed into %2F
+ is transformed into %2B
= is transformed into %3D
and your OCSP responder is supposed to reverse that transformation (only once),
then base-64 decode the string, and continue with the process (OCSP request
parsing, etc).
It seems your OCSP responder doesn't accept URL-encoded OCSP requests, or at
least the %2F.
For exemple,
http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL%2FGhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA%3D
gives a 400 error, and if I change %2F into /, I get an OCSP response.
May this can help you: I think this is the same error that Mr Erwann Abalea
detected on this OCSP Responder in May 2012 (See TURKTRUST Additional Root
Inclusion Request discussion).
Cheers,
J
El miércoles, 4 de marzo de 2015, 17:33:02 (UTC+1), Volkan Nergiz escribió:
Hi All,
#1: As far as we know, our OCSP server already works with HTTP GET requests.
When we analyze the logs, we see many GET requests that are being responded
successfully.
For example, we have generated the OCSP request below, using the openssl
tool, for the certificate of https://testsuite12002.turktrust.com.tr/
MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/GhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA=
When we paste this request to the address bar of Firefox 36.0 as:
http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/GhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA=
we get a successful good answer using HTTP GET.
Could you please share with us the name of the OCSP client tool and the
content of the request, or any other clue that made you think that our OCSP
server does not support HTTP GET?
Best Regards,
Volkan Nergiz
TURKTRUST, Inc.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+volkan.nergiz=turktrust.com...@lists.mozilla.org]
On Behalf Of Jesus F
Sent: Tuesday, March 3, 2015 6:28 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: TurkTrust Root Renewal Request
Hi all,
After some quick test of the OCSP Service I detect the following issues
related to the conformity with CA/Browser Forum Baseline Requirements for the
Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as
required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2:
Test site: https://testsuite12001.turktrust.com.tr
Test site: https://testsuite12002.turktrust.com.tr
Ocsp: http://ocsp.turktrust.com.tr/
#1: OCSP do not respond using GET method. (BR section 13.2.2)
#2: Although the OCSP do not respond good to a non-issued certifcate
(serials FF and 00) (BR Section 13.2.6), it
responds unknown. This is not in accordance with RFC 6960 (section 2.2)
contrary to what is stated in section 7.3 of the CP
(http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf)
Cheers,
J
El martes, 3 de marzo de 2015, 16:37:21 (UTC+1), Volkan Nergiz escribió:
Dear All,
The issue is actually quite clear and explicitly stated in TURKTRUST
CP and CPS documents. Please see
http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf
http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf and
http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf
http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf for the
English versions of TURKTRUST CP and CPS regarding SSL, EV SSL and
Object Signing
(OSC) certificate services.
Currently, TURKTRUST has three explicit OIDs for SSL, EV SSL and OSC
certificates as follows with dedicated policies:
1.TURKTRUST SSL Certificate Policy (2.16.792.3.0.3.1.1.2) covers
OV SSL certificates for servers. SSL Certificates are issued and
maintained in conformity with Normalized Certificate Policy defined
in ETSI TS 102 042.
2.TURKTRUST OSC Policy (2.16.792.3.0.3.1.1.4) covers
certificates related to object signing operations. OSC is issued and
maintained in conformity with Normalized Certificate Policy defined
in ETSI TS 102 042.
3.TURKTRUST EV SSL Policy (2.16.792.3.0.3.1.1.5) covers
certificates related to EV SSL certificates. EV SSL certificates are
issued and maintained in conformity with Extended Validity Certificate
Policy
defined in ETSI TS 102 042.
For EV SSL services, we have a separate EV root in our new hierarchies
Re: TurkTrust Root Renewal Request
Hi all, After some quick test of the OCSP Service I detect the following issues related to the conformity with CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2: Test site: https://testsuite12001.turktrust.com.tr Test site: https://testsuite12002.turktrust.com.tr Ocsp: http://ocsp.turktrust.com.tr/ #1: OCSP do not respond using GET method. (BR section 13.2.2) #2: Although the OCSP do not respond good to a non-issued certifcate (serials FF and 00) (BR Section 13.2.6), it responds unknown. This is not in accordance with RFC 6960 (section 2.2) contrary to what is stated in section 7.3 of the CP (http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf) Cheers, J El martes, 3 de marzo de 2015, 16:37:21 (UTC+1), Volkan Nergiz escribió: Dear All, The issue is actually quite clear and explicitly stated in TURKTRUST CP and CPS documents. Please see http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf and http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf for the English versions of TURKTRUST CP and CPS regarding SSL, EV SSL and Object Signing (OSC) certificate services. Currently, TURKTRUST has three explicit OIDs for SSL, EV SSL and OSC certificates as follows with dedicated policies: 1.TURKTRUST SSL Certificate Policy (2.16.792.3.0.3.1.1.2) covers OV SSL certificates for servers. SSL Certificates are issued and maintained in conformity with Normalized Certificate Policy defined in ETSI TS 102 042. 2.TURKTRUST OSC Policy (2.16.792.3.0.3.1.1.4) covers certificates related to object signing operations. OSC is issued and maintained in conformity with Normalized Certificate Policy defined in ETSI TS 102 042. 3.TURKTRUST EV SSL Policy (2.16.792.3.0.3.1.1.5) covers certificates related to EV SSL certificates. EV SSL certificates are issued and maintained in conformity with Extended Validity Certificate Policy defined in ETSI TS 102 042. For EV SSL services, we have a separate EV root in our new hierarchies as mandated by the CA/Browser Forum EV Guidelines. This is the TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H6 root certificate. For OV SSL and code signing (OSC), we have another separate root certificate, namely TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5 root certificate. For our qualified electronic certificate (QEC) services related to our e-signature based operations, we have a totally different root called H4. This is out of discussion in this context. Hence, the primary distinction related to our discussion is that we have two separate roots for EV SSL services and the others. The second distinction is that, we have separate sub-root certificates, i.e. intermediate certificates, for our OV SSL and OSC certificate services under the root H5. That is to say, all certificate types have different policies, different OIDs, different intermediates and different operational processes. We hope, these explanations clarify the issue for all. Should you have and further questions, please do not hesitate to contact us. Best regards, Volkan NERGİZ Quality Management System Specialist TURKTRUST Information Security Services Inc. Address: Hollanda Caddesi 696. Sokak No: 7 Yıldız, Çankaya 06550 - ANKARA Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01 E-Mail: mailto:volkan.ner...@turktrust.com.tr volkan.ner...@turktrust.com.tr Web: http://www.turktrust.com.tr/ www.turktrust.com.tr ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: LuxTrust Root Inclusion Request
After some quick test of the OCSP Service I detect the following issues related to the conformity with CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2: Test site: https://www.trustme.lu/ Ocsp: http://ssl.ocsp.luxtrust.lu #1: OCSP do not respond using GET method. (BR section 13.2.2) #2: OCSP respond good to a non-issued certifcate (serials and 00) (BR Section 13.2.6) Cheers, J El jueves, 12 de febrero de 2015, 22:27:37 (UTC+1), David Keeler escribió: On 02/11/2015 04:57 PM, Kathleen Wilson wrote: LuxTrust has applied to include the LuxTrust Global Root root certificate, turn on the Websites and Code Signing trust bits, and enable EV treatment. ... * Potentially Problematic Practices (http://wiki.mozilla.org/CA:Problematic_Practices) ** None Noted. In the certificate transparency log, I've noted a few problems with certificates as currently issued by C=LU, O=LuxTrust S.A., CN=LuxTrust Qualified CA. * They all appear to be signed with sha1WithRSAEncryption. This algorithm is deprecated - sha256WithRSAEncryption should be used instead. * Many do not have the Subject Alternative Names extension and instead use the Subject Common Name field to identify a DNS name or IP address. This behavior is also deprecated. * At least one certificate was issued for a 1024 bit RSA key. The minimum should be 2048 bits for RSA. * The Netscape Cert Type extension appears to be common. This is not part of rfc 5280 and shouldn't be used. Here are some example certificates that illustrate these issues: -BEGIN CERTIFICATE- MIIFjDCCBHSgAwIBAgIDBmRtMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs aWZpZWQgQ0EwHhcNMTUwMTMwMDk0ODUwWhcNMTYwMTMwMDk0ODUwWjCBkDELMAkG A1UEBhMCTFUxEzARBgNVBAgTCkx1eGVtYm91cmcxEzARBgNVBAcTCkx1eGVtYm91 cmcxITAfBgNVBAoTGEFyY2hldmVjaGUgZGUgTHV4ZW1ib3VyZzEWMBQGA1UEAxMN d3d3LmNhdGhvbC5sdTEcMBoGCSqGSIb3DQEJARYNc2NwQGNhdGhvbC5sdTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpuN3DMSGzZpom8PBa3TwnJKUXd V2muUkKhpcy2wOZuksI+Aka0JQxn9YujP9fhkHsWug+1C+RVKb4DfljRwgc4Kfbw 5Bejtmw3DsrMKQxDZPljuf7qXnW7S7K3cCCtwJJcyJbzoPhnaJF7grVXgaduLAP8 WSsewkqMAj32dFOo1dR2G7Jtlg1Kb5h1DtGthrPumH1BIz9INQ9ewX+/f2cYRLTn Ql1fwCToNrzwVaL4oEPeWjlVvzCXi2KrmNDSnsCcU1lnuBn3pjhV9asgTbTirPyc zp3eXAzF7t+84qfv7uqLTj61QY2wvPA7QEOw7o5zm+RFReAuUQzKRHXUiNMCAwEA AaOCAjcwggIzMAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDov L2NhLmx1eHRydXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4Er AQECBgEwgdswga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRp ZmljYXRlLiBOb3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5 IFN1YnNjcmliZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9y eS5sdXh0cnVzdC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEF BQcCARYdaHR0cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEG CWCGSAGG+EIBAQQEAwIF4DAOBgNVHQ8BAf8EBAMCBLAwJwYDVR0lBCAwHgYIKwYB BQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDBDAfBgNVHSMEGDAWgBSNkKMH3RoTd5lM kqtNQ94/zSlkBTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmx1eHRydXN0 Lmx1L0xUUUNBLmNybDAdBgNVHQ4EFgQU3T0x0fyh2toW9B/kYF+LjOGcMYYwDQYJ KoZIhvcNAQEFBQADggEBALJFjVrAuSU3pZuCGQ7sVM8hDVfDrt9slpziu2yQoBKg VKblu3yK4+Rs8DgcNvPB38fOKRYU1MZBhLSUMkt90jfUJJXiMHxxZt3Av5el4mNX VdYw57hcoyHbBHWqjKgIGCKN8blAOk08VD7s614wNA0DChXL+SqnrhkKPRlTmVa/ /T9iGqA2agX6RNTdCt2E0DalAUcFM6mRIhMIS+xyuB29wdZce+q8N5zFW6mZQi7W WYlrZvYBKQdWhaeZMaQAuAo11gtG8p0QtrIZmR/pBhzBiOfVVMh6Co7M0u3xI1T0 RW/C6hxMRAomcYKW4OpUtrr2ImQUmQgustSK0uhqdMM= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIE3zCCA8egAwIBAgIDBiXvMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkxV MRYwFAYDVQQKEw1MdXhUcnVzdCBTLkEuMR4wHAYDVQQDExVMdXhUcnVzdCBRdWFs aWZpZWQgQ0EwHhcNMTQwNjI1MTQxODMxWhcNMTYxMDE4MTA0MDM0WjB8MQswCQYD VQQGEwJMVTETMBEGA1UECBMKTHV4ZW1ib3VyZzERMA8GA1UEBxMIQ2FwZWxsZW4x FjAUBgNVBAoTDUx1eFRydXN0IFMuQS4xFTATBgNVBAsTDEFwcGxpY2F0aW9uczEW MBQGA1UEAxMNMTk0LjM2LjIyNy42NjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEApdjys8GcCORTGqltPf7cvXTsD/PjSjHFvVyYWQclgDHjnOVVXHAZFMCE76MD 76Er3Egfg5vFQYFh8NHbNQKlUCc3Ljn6S/i1FhYBV4tYvqaGbX8z9Xyh+V7sOUL4 poqKQ/LPoZ7smpVIXlAHHSmWiWPHTY9HHaEBpWLmgJsSad0CAwEAAaOCAiMwggIf MAwGA1UdEwEB/wQCMAAwYAYIKwYBBQUHAQEEVDBSMCMGCCsGAQUFBzABhhdodHRw Oi8vb2NzcC5sdXh0cnVzdC5sdTArBggrBgEFBQcwAoYfaHR0cDovL2NhLmx1eHRy dXN0Lmx1L0xUUUNBLmNydDCCAQAGA1UdIASB+DCB9TCB6AYIK4ErAQECBgEwgdsw ga0GCCsGAQUFBwICMIGgGoGdTHV4VHJ1c3QgU2VydmVyIENlcnRpZmljYXRlLiBO b3Qgc3VwcG9ydGVkIGJ5IFNTQ0QsIEtleSBHZW5lcmF0aW9uIGJ5IFN1YnNjcmli ZXIuIEdUQywgQ1AgYW5kIENQUyBvbiBodHRwOi8vcmVwb3NpdG9yeS5sdXh0cnVz dC5sdS4gU2lnbmVkIGJ5IGEgUXVhbGlmaWVkIENBLjApBggrBgEFBQcCARYdaHR0 cDovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCAYGBACPegEDMBEGCWCGSAGG+EIB AQQEAwIF4DAOBgNVHQ8BAf8EBAMCBLAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHwYD
