Closed Bug 1445364 Opened 7 years ago Closed 4 years ago

Microsec new (ECC) Root Inclusion Request

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: szoke.sandor, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.54, FF 79)

Attachments

(8 files)

AA2017121402_Root_2017_s.pdf
559.61 KB, application/pdf
Details
AA2018121303_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf
380.53 KB, application/pdf
Details
Microsec's_BR_Self_Assessment-v2.8-20190109.xlsx
97.91 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
Microsec_CA_Information.pdf
606.43 KB, application/pdf
Details
AA2018121302_Microsec-eSzignoRoot-CA-2009_EV-CAs_s.pdf
307.23 KB, application/pdf
Details
AA2018121304_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf
307.19 KB, application/pdf
Details
Microsec's_BR_Self_Assessment_EV-v2.8-20190115.xlsx
98.78 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
Mozilla-04.docx
55.20 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36 Steps to reproduce: Our first root „Microsec e-Szigno Root CA” expired in April, 2017. Presently we have one valid root "Microsec e-Szigno Root CA 2009" in CCADB which will expire in december 2029. Last year we decided to set up a new CA hierarchy based on ECC algorithm. The new hierarchy contains the same structure like our present RSA based hierarchy. The only difference is that in the present hierarchy we issue the TSA certificates directly from the Root CA, but in the new hierarchy we set up a dedicated TSA intermediate CA under the root to issue the TSA certificates. Actual results: The whole hierarchy was tested during our last conformity assessment audit in 2017 and the auditor (TÜViT) issued a separate attestation letter for this new CA hierarchy. The certificate for the new Microsec root CA is as follows: "e-Szigno Root CA 2017" -----BEGIN CERTIFICATE----- MIICQDCCAeWgAwIBAgIMAVRI7yH9l1kN9QQKMAoGCCqGSM49BAMCMHExCzAJBgNV BAYTAkhVMREwDwYDVQQHDAhCdWRhcGVzdDEWMBQGA1UECgwNTWljcm9zZWMgTHRk LjEXMBUGA1UEYQwOVkFUSFUtMjM1ODQ0OTcxHjAcBgNVBAMMFWUtU3ppZ25vIFJv b3QgQ0EgMjAxNzAeFw0xNzA4MjIxMjA3MDZaFw00MjA4MjIxMjA3MDZaMHExCzAJ BgNVBAYTAkhVMREwDwYDVQQHDAhCdWRhcGVzdDEWMBQGA1UECgwNTWljcm9zZWMg THRkLjEXMBUGA1UEYQwOVkFUSFUtMjM1ODQ0OTcxHjAcBgNVBAMMFWUtU3ppZ25v IFJvb3QgQ0EgMjAxNzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJbcPYrYsHtv xie+RJCxs1YVe45DJH0ahFnuY2iyxl6H0BVIHqiQrb1TotreOpCmYF9oMrWGQd+H Wyx7xf58etqjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBSHERUI0arBeAyxr87GyZDvvzAEwDAfBgNVHSMEGDAWgBSHERUI0arB eAyxr87GyZDvvzAEwDAKBggqhkjOPQQDAgNJADBGAiEAtVfd14pVCzbhhkT61Nlo jbjcI4qKDdQvfepz7L9NbKgCIQDLpbQS+ue16M9+k/zzNY9vTlp8tLxOsvxyqltZ +efcMQ== -----END CERTIFICATE----- Expected results: Please include this new root certificate in your root certificate program and CCADB.
The attestation letter for our new Root issued by TÜViT
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process: https://wiki.mozilla.org/CA/Application_Process#Process_Overview In the meantime, please provide the checklist information and BR Self Assessment (if different from the one that was previously provided in response to the CA Communication). https://wiki.mozilla.org/CA/Information_Checklist
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - need checklist info and BR Self Assessment
We publish the new version of our CP and CPS documents from the 24th of March 2018. We will upgrade our self assessment report and I will upload the new version to this bug. I will upload also the checklist document next week
Still need the checklist information and BR Self Assessment (if different from the one that was previously provided in response to the CA Communication). https://wiki.mozilla.org/CA/Information_Checklist
We issued the new version of our public documents on the 15th of September 2018. We will update our BR Self Assessment and upload the new version soon. We will prepare the reqested checklist information too.

I attach the new attestation letter for our new ECC hierarchy.

We issued the version 2.8 of our public documents on the 14th of December 2018. We upgrade our self assessment report and upload it soon.

I upload the latest version of our self assessment report.

I upload the checklist information.

Microsec plans to launch the issuance of EV certificates and request to set the EV flag both in this new root CA and the existing active root CA.

Shall I include this information into this bug or shall I open a separate bug for the EV issue to manage it separately?

(In reply to dr. Sándor SZŐKE from comment #9)

Microsec plans to launch the issuance of EV certificates and request to set the EV flag both in this new root CA and the existing active root CA.

Shall I include this information into this bug or shall I open a separate bug for the EV issue to manage it separately?

The request for EV can be processed at the same time as the request for root inclusion. So please add the EV info to this bug.

QA Contact: kwilson

(In reply to Kathleen Wilson from comment #10)

(In reply to dr. Sándor SZŐKE from comment #9)

Microsec plans to launch the issuance of EV certificates and request to set the EV flag both in this new root CA and the existing active root CA.

Shall I include this information into this bug or shall I open a separate bug for the EV issue to manage it separately?

The request for EV can be processed at the same time as the request for root inclusion. So please add the EV info to this bug.

OK, I will upload the EV Attestation letters for both CA hierarchies. We will review the Self Assessment report regarding the EV services and I will upload the EV S.A.

EV Attestation Letter for the already included Microsec Root
"Microsec e-Szigno Root CA 2009"

EV Attestation Letter for the new - ECC based - Microsec Root
"e-Szigno Root CA 2017"

In the CA's document repository (https://e-szigno.hu/en/pki-services/certificate-policies-general-terms-and-conditions/) there are the following documents.

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.8.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.8.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.8.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.8.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.8.pdf

Not eIDAS conform Certificates Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--uni--EN--v2.8.pdf

Non eIDAS covered Certificate Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--uni--EN--v2.8.pdf

eIDAS conform Non Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/kiv--fok--ssl--EN--v2.8.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.8.pdf

Which of these apply to the "e-Szigno Root CA 2017" root and its CA Hierarchy?

I had assumed that they all do, but some of them, such as szsz--fok--uni--EN--v2.8.pdf, do not contain important things like how Domain validation is done for TLS certs.

Whiteboard: [ca-verifying] - need checklist info and BR Self Assessment → [ca-verifying]

I give you another link for our public documents, where you can find all of the earlier versions of all public documents too:

https://e-szigno.hu/en/terms-and-informations/all-documents.html

Microsec issues several types of certificates according to the classification of the EU regulations (eIDAS). These classes are:
• certificates for electronic signatures (digital signing certificates for natural persons)
• certificates for electronic seals (digital signing certificates for legal person)
• certificates for website authentication (TLS certificates)

Microsec also issues other types of certificates which are out of the scope of the EU regulations (client authentication, encryption etc.).

Microsec issues qualified and non qualified certificates according to the eIDAS requirements. Qualified certificate means a higher level of requirements and auditing of the services and this way results the automatic mutual acceptance of these type of certificates in the EU member states. The qualified status is indicated in the QCStatements extension of the enduser certificates.

According to these requirements Microsec has the following certification services, which are covered by separate public documents:
• eIDAS conform Qualified Certificate for Electronic Signature
• eIDAS conform Non-Qualified Certificate for Electronic Signature
• eIDAS conform Qualified Certificate for Electronic Seal
• eIDAS conform Non-Qualified Certificate for Electronic Seal
• eIDAS conform Qualified Certificate for Website Authentication
• eIDAS conform Certificate for Website Authentication
• Non eIDAS covered Certificates

All services has Certificate Policy (CP) and Certification Practice Statement (CPS) document and for several services Microsec has Disclosure Statement, which is an abstract of the CPS.

Each type of certificates are issued under each of our root CA-s, but from different subordinate CA-s. The details can be found in each CPS document in the chapter
1.3.1 Certification Authorities
Certification Units

So you are perfect, all of the listed documents are relevant for each root CA.

For the DV, OV and IV type of TLS certificates the following service is relevant:
• eIDAS conform Certificate for Website Authentication

For the EV certificates the following service is relevant:
• eIDAS conform Qualified Certificate for Website Authentication

The domain validation rules and other TLS related regulations can be found in these CPS documents. Other documents are out of the scope of TLS, but they are relevant because other types of certificates are issued from subordinate CA-s which can be also chained to the root which is included in the Mozilla root store.

The TÜViT audit and the issued attestation letters cover all of our root and subordinate CA-s.

The latest self assessment for the EV certificates.

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

When logged into the CCADB you can directly see the Case here: https://ccadb.force.com/5001J00000abH11

Please check the information, and provide updates/corrections especially for sections containing the word "NEED".

In Particular:

  1. Are these audit statements available on the tuvit.de website?
    If yes, please provide those URLs.
    If no, I will need to contact the auditor to confirm the authenticity of the documents.

  2. CAA is described in DV and EV CPS section 4.2.2, but I did not find the set of domain names that the CA recognizes in CAA.
    https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
    Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.

  3. Resolve all revocation check errors here:
    https://certificate.revocationcheck.com/ec3sslca2017-valid.e-szigno.hu
    and
    https://certificate.revocationcheck.com/pca.e-szigno.hu

  4. When requesting EV treatment, the TLS certs for the test websites must be EV. And also need successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

  5. Add records for the intermediate certs in the "e-Szigno Root CA 2017" CA Hierarchy to the CCADB as per
    https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

  6. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

Whiteboard: [ca-verifying] → [ca-verifying] - KW 2019-01-29 - Comment #15

(In reply to Kathleen Wilson from comment #17)

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

When logged into the CCADB you can directly see the Case here: https://ccadb.force.com/5001J00000abH11

Please check the information, and provide updates/corrections especially for sections containing the word "NEED".

In Particular:

  1. Are these audit statements available on the tuvit.de website?
    If yes, please provide those URLs.
    If no, I will need to contact the auditor to confirm the authenticity of the documents.

The Audit information is available directly on the TÜViT web site. Microsec has four audit letters on the following links:

e-Szigno Root CA 2017
non EV
AA2018121303
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121303_Microsec-eSzignoRoot-CA-2017_nonEV-CAs_s.pdf

e-Szigno Root CA 2017
EV
AA2018121304
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121304_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf

Microsec e-Szigno Root CA 2009
non EV
AA2018121301
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121301_Microsec-eSzignoRoot-CA-2009_nonEV-CAs_s.pdf

Microsec e-Szigno Root CA 2009
EV
AA2018121302
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018121302_Microsec-eSzignoRoot-CA-2009_EV-CAs_s.pdf

  1. CAA is described in DV and EV CPS section 4.2.2, but I did not find the set of domain names that the CA recognizes in CAA.
    https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
    Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.

Microsec will put more information to the next version of the CPS about the CAA handling process, including the set of Issuer Domain Names that Microsec recognises in CAA "issue" or "issuewild" records as permitting it to issue.

  1. Resolve all revocation check errors here:
    https://certificate.revocationcheck.com/ec3sslca2017-valid.e-szigno.hu
    and
    https://certificate.revocationcheck.com/pca.e-szigno.hu

We will check this issue.

  1. When requesting EV treatment, the TLS certs for the test websites must be EV. And also need successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Microsec has 4 set of test web sites for test purposes, each includes sites with valid, revoked and expired certificate.
These test sides are:

RSA based non EV certificates issued by the presently active root:
https://sslca2014-valid.e-szigno.hu
https://sslca2014-expired.e-szigno.hu
https://sslca2014-revoked.e-szigno.hu

ECC based non EV certificates issued by the new root:
https://ec3sslca2017-valid.e-szigno.hu
https://ec3sslca2017-expired.e-szigno.hu
https://ec3sslca2017-revoked.e-szigno.hu

RSA based EV certificates issued by the presently active root:
https://qtlsca2018-valid.e-szigno.hu
https://qtlsca2018-expired.e-szigno.hu
https://qtlsca2018-revoked.e-szigno.hu

ECC based EV certificates issued by the new root:
https://eqtlsca2018-valid.e-szigno.hu
https://eqtlsca2018-expired.e-szigno.hu
https://eqtlsca2018-revoked.e-szigno.hu

We will supply the output of the successfull test soon.

  1. Add records for the intermediate certs in the "e-Szigno Root CA 2017" CA Hierarchy to the CCADB as per
    https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

I have added all the new subordinate certificates to the CCADB under the new root.

  1. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

We will check the test errors.
At the first look I think that most of the test report errors are caused because non TLS certificates are tested as a TLS certificate.
We will check the reports more deeply and answer them soon.

I updated the Case in the CCADB

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

Remaining items that need to be resolved before this request can move to the 'In Detailed CP/CPS Review' phase:

  1. Resolve all revocation check errors for the following:
    https://certificate.revocationcheck.com/ec3sslca2017-valid.e-szigno.hu
    https://certificate.revocationcheck.com/eqtlsca2018-valid.e-szigno.hu
    https://certificate.revocationcheck.com/pca.e-szigno.hu
    https://certificate.revocationcheck.com/qtlsca2018-valid.e-szigno.hu

  2. Resolve EV Testing error for "e-Szigno Root CA 2017" root.
    https://tls-observatory.services.mozilla.com/static/ev-checker.html with
    https://eqtlsca2018-valid.e-szigno.hu/
    2.23.140.1.1
    Result: Stderr: BuildCertChain failed: SEC_ERROR_OCSP_UNKNOWN_CERT The OCSP server has no status for the certificate.

  3. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

Whiteboard: [ca-verifying] - KW 2019-01-29 - Comment #15 → [ca-verifying] - KW 2019-01-30 - Comment #19

(In reply to Kathleen Wilson from comment #19)

I updated the Case in the CCADB

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

Remaining items that need to be resolved before this request can move to the 'In Detailed CP/CPS Review' phase:

  1. Resolve all revocation check errors for the following:
    https://certificate.revocationcheck.com/ec3sslca2017-valid.e-szigno.hu
    https://certificate.revocationcheck.com/eqtlsca2018-valid.e-szigno.hu
    https://certificate.revocationcheck.com/pca.e-szigno.hu
    https://certificate.revocationcheck.com/qtlsca2018-valid.e-szigno.hu

We have resolved the problems and we have checked all 12 (+1 old) Microsec test TLS sites with the site https://certificate.revocationcheck.com.

There is no any error message only some warnings. The caching on the test program caused some difficulties for us, it was not easy tho check the modified OCSP responses due to the cashed test results.

Tha main problem was on our side that the OCSP responder of the root CA did not contain the NextUpdate value. Microsec used this value only for the intermediate TLS CA OCSP responders.

We have modified the OCSP responders on the root CA-s and now they already set the NextUpdate value.

Microsec generates a new OCSP response for each incoming OCSP request, so each OCSP response is valid and contains actual status information. Microsec uses very short validity OCSP signing certificates (10 minutes) which is not practical for OCSP stapling.

In the very near future we will change the root OCSP responders to use longer validity OCSP sertificates and we will set a longer (later) value for the NextUpdate.

(In reply to Kathleen Wilson from comment #19)

  1. Resolve EV Testing error for "e-Szigno Root CA 2017" root.
    https://tls-observatory.services.mozilla.com/static/ev-checker.html with
    https://eqtlsca2018-valid.e-szigno.hu/
    2.23.140.1.1
    Result: Stderr: BuildCertChain failed: SEC_ERROR_OCSP_UNKNOWN_CERT The OCSP server has no status for the certificate.

we have checked all the 6 test sites with your EV test program https://tls-observatory.services.mozilla.com/static/ev-checker.html

The test results can be found below:

For the presently active RSA based system:

Microsec e-Szigno Root CA 2009

-----BEGIN CERTIFICATE-----
MIIECjCCAvKgAwIBAgIJAMJ+QwRORz8ZMA0GCSqGSIb3DQEBCwUAMIGCMQswCQYD
VQQGEwJIVTERMA8GA1UEBwwIQnVkYXBlc3QxFjAUBgNVBAoMDU1pY3Jvc2VjIEx0
ZC4xJzAlBgNVBAMMHk1pY3Jvc2VjIGUtU3ppZ25vIFJvb3QgQ0EgMjAwOTEfMB0G
CSqGSIb3DQEJARYQaW5mb0BlLXN6aWduby5odTAeFw0wOTA2MTYxMTMwMThaFw0y
OTEyMzAxMTMwMThaMIGCMQswCQYDVQQGEwJIVTERMA8GA1UEBwwIQnVkYXBlc3Qx
FjAUBgNVBAoMDU1pY3Jvc2VjIEx0ZC4xJzAlBgNVBAMMHk1pY3Jvc2VjIGUtU3pp
Z25vIFJvb3QgQ0EgMjAwOTEfMB0GCSqGSIb3DQEJARYQaW5mb0BlLXN6aWduby5o
dTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOn4j/NjrdqG2KfgQvvP
kd6mJviZpWNwrZuuyjNAfW2WbqEORO7hE52UQlKavXWFdCyoDh2Tthi3jCyoz/tc
cbna7P7ofo/kLx2yqHWH2Leh5TvPmUpG0IMZfcChEhyVbUr02MelTTMuhTlAdX4U
fIASmFDHQWe4oIBhVKZsTh/gnQ4H6cm6M+f+wFUoLAKApxn1ntxVUwOXewdI/5n7
N4okxFnMUBBjjqqpGrCEGob5X7uxUG6k0QrM1XF+H6cbfPVTbiJfyyvm1HxdrtbC
xkzlBQHZ7Vf8wSN5/PrIJIOV87VqUQHQd9bpEqH5GoP7ghu5sJf0dgYzQ0mg/wu1
+rUCAwEAAaOBgDB+MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBTLD8bfQkPMPcu1SCOhGnqmKrs0aDAfBgNVHSMEGDAWgBTLD8bfQkPM
Pcu1SCOhGnqmKrs0aDAbBgNVHREEFDASgRBpbmZvQGUtc3ppZ25vLmh1MA0GCSqG
SIb3DQEBCwUAA4IBAQDJ0Q5eLtXMs3w+y/w9/w0olZMEyL/azXm4Q5DwpL7v8u8h
mLzU1F0G9u5C7DBsoKqpyvGvivo/C3NqPuouQH4frlRheesuCDfXI/OMn74dseGk
ddug4lQUsbocKaQY9hK6ohQU4zE1yED/t+AFdlfBHFny+L/k7SViXITwfn4fs775
tyERzAMBVnCnEJIeGzSBHq2cGsMEPO0CYdYeBvNfOofyK/FFh+U9rNHHV4S9a67c
2Pm2G2JwCz02yULyMtd6YebS2z3PyKnJm9zbWETXbzivf3jTo60adbocwTZ8jx5t
HMN1Rq41Bab2XD0h7lbwyYIiLXpUq3DDfSJlgnCW
-----END CERTIFICATE-----

'---------------------------------------------
EV-Readiness Check
ev-checker exited successfully: Success!

TLS Server

https://qtlsca2018-valid.e-szigno.hu
EV Policy OID

2.23.140.1.1

'-------------------------------------------

EV-Readiness Check
ev-checker exited successfully: exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_EXPIRED_CERTIFICATE Peer's Certificate has expired.

TLS Server

https://qtlsca2018-expired.e-szigno.hu
EV Policy OID

2.23.140.1.1

'------------------------------------------

EV-Readiness Check
ev-checker exited successfully: exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_REVOKED_CERTIFICATE Peer's Certificate has been revoked.

TLS Server

https://qtlsca2018-revoked.e-szigno.hu
EV Policy OID

2.23.140.1.1

'------------------------------------------

For the new ECC based system:

e-Szigno Root CA 2017

-----BEGIN CERTIFICATE-----
MIICQDCCAeWgAwIBAgIMAVRI7yH9l1kN9QQKMAoGCCqGSM49BAMCMHExCzAJBgNV
BAYTAkhVMREwDwYDVQQHDAhCdWRhcGVzdDEWMBQGA1UECgwNTWljcm9zZWMgTHRk
LjEXMBUGA1UEYQwOVkFUSFUtMjM1ODQ0OTcxHjAcBgNVBAMMFWUtU3ppZ25vIFJv
b3QgQ0EgMjAxNzAeFw0xNzA4MjIxMjA3MDZaFw00MjA4MjIxMjA3MDZaMHExCzAJ
BgNVBAYTAkhVMREwDwYDVQQHDAhCdWRhcGVzdDEWMBQGA1UECgwNTWljcm9zZWMg
THRkLjEXMBUGA1UEYQwOVkFUSFUtMjM1ODQ0OTcxHjAcBgNVBAMMFWUtU3ppZ25v
IFJvb3QgQ0EgMjAxNzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJbcPYrYsHtv
xie+RJCxs1YVe45DJH0ahFnuY2iyxl6H0BVIHqiQrb1TotreOpCmYF9oMrWGQd+H
Wyx7xf58etqjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBSHERUI0arBeAyxr87GyZDvvzAEwDAfBgNVHSMEGDAWgBSHERUI0arB
eAyxr87GyZDvvzAEwDAKBggqhkjOPQQDAgNJADBGAiEAtVfd14pVCzbhhkT61Nlo
jbjcI4qKDdQvfepz7L9NbKgCIQDLpbQS+ue16M9+k/zzNY9vTlp8tLxOsvxyqltZ
+efcMQ==
-----END CERTIFICATE-----

'---------------------------------------------------

EV-Readiness Check
ev-checker exited successfully: Success!

TLS Server

eqtlsca2018-valid.e-szigno.hu
EV Policy OID

2.23.140.1.1

'--------------------------------------------------

EV-Readiness Check
ev-checker exited successfully: exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_EXPIRED_CERTIFICATE Peer's Certificate has expired.

TLS Server

https://eqtlsca2018-expired.e-szigno.hu
EV Policy OID

2.23.140.1.1

'--------------------------------------------------

EV-Readiness Check
ev-checker exited successfully: exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_REVOKED_CERTIFICATE Peer's Certificate has been revoked.

TLS Server

https://eqtlsca2018-revoked.e-szigno.hu
EV Policy OID

2.23.140.1.1

'-------------------------------------------------

(In reply to Kathleen Wilson from comment #19)

I updated the Case in the CCADB

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

Remaining items that need to be resolved before this request can move to the 'In Detailed CP/CPS Review' phase:

  1. Resolve all revocation check errors for the following:
    https://certificate.revocationcheck.com/ec3sslca2017-valid.e-szigno.hu
    https://certificate.revocationcheck.com/eqtlsca2018-valid.e-szigno.hu
    https://certificate.revocationcheck.com/pca.e-szigno.hu
    https://certificate.revocationcheck.com/qtlsca2018-valid.e-szigno.hu

https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

There are many links to many pages, we try to cover all the issues below.

The ERRORs are false, because non TLS certificates were checked against the TLS requirements. The

Certificates:
https://crt.sh/?id=194998&opt=cablint,zlint,x509lint
https://crt.sh/?id=149444539&opt=cablint,zlint,x509lint

Microsec e-Szigno Root CA 2009

The root certificate (private key) is not used to sign OCSP responses directly. The root CA issues OCSP responder certificates and the OCSP responders sign the OCSP responses.
This root certificates contains the emailAddress value in the SAN. The new CA certificates do not contain this field.

CA/B Forum lint

WARNING: Name has deprecated attribute emailAddress in 29 certificates

All these certificates are OCSP responder certificates, they contain the emailAddress value in the SAN.

WARNING: Name has unknown attribute 2.5.4.97 6 affected certs

These 6 certificates are subordinate CA certificates operated by Microsec. The OID 2.5.4.97 a standard field OrganizationIdentifier which is requested by the ETSI standard for the CA-s operated in the EU.

X.509 lint

ERROR: Invalid type in SAN entry in 42 certificates

There are two types of certificates among them:
OCSP responder certificates
Time stamping certificates

The use of the emailAddress in the SAN is not forbidden for these certificates.

ERROR: No OCSP over HTTP in 23 certificates

All these certificates are OCSP responder certificates.
Microsec uses very short life OCSP certificates (< 1 day). There is no revocation service for these certificates, the OCSP no check extension is indicated in the certificates.

ERROR: The certificate is valid for longer than 60 months in 18 certificates

In the list there are 2 subordinate CA certificates and 16 time stamping certificates which are out of the scope of the BR, they may have longer validity than 60 months.

ERROR: No Subject alternative name extension in 2 certificates

They are time stamping certificates and they do not contain SAN field.

ZLint

ERROR: DNSNames must have a valid TLD. in 1 certificate

Qualified eIDAS e-Szigno TSA 2017 02 is a time stamping certificate, it does not contain any domain name.

ERROR: The common name field in subscriber certificates must include only names from the SAN extension

Qualified eIDAS e-Szigno TSA 2017 02 is a time stamping certificate, it does not contain SAN.

ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period no greater than 39 months.

Qualified eIDAS e-Szigno TSA 2017 02 is a time stamping certificate, it may have validity longer than 39 months.

ERROR: Subscriber certificates MUST contain the Subject Alternate Name extension

Qualified eIDAS e-Szigno TSA 2017 02 is a time stamping certificate, it do not have to contain SAN.

ERROR: Characters in labels of DNSNames MUST be alphanumeric, - , _ or *

Qualified eIDAS e-Szigno TSA 2017 02 is a time stamping certificate, the fields in the DNSNames may contain other characters too, like space (’ ’) and dot (’.’).

(In reply to Kathleen Wilson from comment #19)

  1. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

CA/B Forum lint

WARNING: Name has unknown attribute 2.5.4.97

The 2.5.4.9.7 OID is the organizationIdentifier which is requested by the European norms when the organizationName contains the name of a legal person.

X.509 lint

ERROR: No OCSP over HTTP in 26 certificates

All these certificates are OCSP responder certificates.
Microsec uses very short life OCSP certificates (< 1 day). There is no revocation service for these
certificates, the OCSP no check extension is indicated in the certificates.

ERROR: No Subject alternative name extension in 19 certificates

All these certificates are OCSP responder certificates.
They do not contain SAN

ERROR: Subject with givenName or surname but without the CAB IV policy oid 1 certificate

It was an IVCP certificate issued during the audit in 2018-09-14 09:21:06 GMT
It contains the Microsec Policy OID 1.3.6.1.4.1.21528.2.1.1.161.2.6 and the link to the site where the CPS is published. The CPS contains information, that this OID is conformant to the CABF IVCP policy

The certificate contains also the following OID: 0.4.0.2042.1.8
It is specified by ETSI EN 319 411-1 in section 5.3 g/ as an IVCP OID, which is equivalent to the CABF IVCP OID 2.23.140.1.2.3.

The certificate was revoked at 2018-09-16 19:20:18 ÚT.

Microsec will modify the TLS certificate profiles and will include also the CABF policy OID in the TLS certificates.

ZLint

ERROR: Subscriber Certificate: A certificate containing a subject:givenName field or subject:surname field MUST contain the (2.23.140.1.2.3) certPolicy OID.

The same issue as described above.

(In reply to Kathleen Wilson from comment #19)

  1. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

CA/B Forum lint

WARNING: Name has unknown attribute 2.5.4.97

The 2.5.4.9.7 OID is the organizationIdentifier which is requested by the European norms when the organizationName contains the name of a legal person.

X.509 lint

ERROR: No OCSP over HTTP in 26 certificates

All these certificates are OCSP responder certificates.
Microsec uses very short life OCSP certificates (< 1 day). There is no revocation service for these
certificates, the OCSP no check extension is indicated in the certificates.

ERROR: No Subject alternative name extension in 19 certificates

All these certificates are OCSP responder certificates.
They do not contain SAN

Attached file Mozilla-04.docx —

(In reply to Kathleen Wilson from comment #19)

  1. Resolve/Explain lint test errors for the "Microsec e-Szigno Root CA 2009" root and subCAs.
    https://crt.sh/?caid=778&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33787&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=33785&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01
    https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

https://crt.sh/?caid=1536&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01

The link contains several ERROR messages, so it was hardly impossible to answer all in a message window.

Instead of this I created a .docx file which I upload to this bug.

Several ERRORs are indicated in more than one pages, this case I haven't written the full answer to all places, only a notice that that issue has been already answered.

Most of the problems are old and have been already solved. The faulty certificates has been revoked or expired, our program has been improved to avoid having that problem again.

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000274

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-01-30 - Comment #19 → [ca-cps-review] - KW 2019-02-12

Mainly to reflect the recent changes in the BR and the EVG Microsec issued the new version of its public SSL/TLS documents on 2019-04-24.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.9.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.9.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.9.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.9.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.9.pdf

Mainly to reflect the recent changes in the EVG Microsec issued the new version of its public SSL/TLS documents on 2019-06-25.
The new version supports the issuance of the PSD2 certificates which are compliant to CABF EVG and eIDAS QWAC.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.10.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.10.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.10.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.10.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.10.pdf

I'am happy to inform you that Microsec has successfully updated its CA system and now it is able to support the new certificate extension cabfOrganizationIdentifier (OID: 2.23.140.3.1).

You can find below our first issued live EV/QWAC TLS certificate with this extension set:

-----BEGIN CERTIFICATE-----
MIILDDCCCfSgAwIBAgIOATxz8CxE1TtGx/fejwowDQYJKoZIhvcNAQELBQAwejEL
MAkGA1UEBhMCSFUxETAPBgNVBAcMCEJ1ZGFwZXN0MRYwFAYDVQQKDA1NaWNyb3Nl
YyBMdGQuMRcwFQYDVQRhDA5WQVRIVS0yMzU4NDQ5NzEnMCUGA1UEAwweUXVhbGlm
aWVkIGUtU3ppZ25vIFRMUyBDQSAyMDE4MB4XDTE5MDgxMjEyMjQxOFoXDTIwMDgx
MjEyMjQxOFowgfcxEzARBgsrBgEEAYI3PAIBAxMCREUxGTAXBgsrBgEEAYI3PAIB
AQwITcO8bmNoZW4xHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYD
VQQFEwpIUkIgMjE4Njc1MQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREw
DwYDVQQHDAhNw7xuY2hlbjEUMBIGA1UECgwLU09GT1JUIEdtYkgxGzAZBgNVBGEM
ElBTRERFLUJBRklOLTE1MTc4ODEUMBIGA1UECwwLRW5naW5lZXJpbmcxFzAVBgNV
BAMMDnd3dy5zb2ZvcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAsprZeVZlTyrnuNzzXRD6rBm8SPSWJfo4fka5vOcmLAW3FeerxcFphmhouuF3
WJ5rwDIcfn5ktro2vjYWGyRMtd6JqVw3gB8FZsv+T7eJv93MyhJtAXWUCXLLooux
gkoSlhbiPnHr2Q3vrnwsLtbkLYINUQcGV5S0p+gpBqcDU/uq7VFc790cQHx0ktLA
O6tQo6lx/46D5SU2RHjxZSPhKv1HENjQwzKJLX0p2tryClq0lznHW/qLe9DWAg0T
EIXG18MDDuDMW0bWoqP8bi8hToqoabwg3zF4Drs0q14JM2CGWJ7oGOO4e/9/iHcl
kA8NvTAyaIEjOkTn9fnmHNWyiQIDAQABo4IHEDCCBwwwDgYDVR0PAQH/BAQDAgWg
MIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCyHgXMi6LNiiBOh2b5K7mKJSBn
a9r6cOeySVMt74uQXgAAAWyFyVI/AAAEAwBHMEUCIBlNFmbH+myKUzZqukcDLul8
LPJoHkFmkvJ4meNif6EeAiEAmXKIGRS1BntQMkOnOaKZ6PJ9AMZz4K7lpr1uJ1db
5/0AdQBVgdTCFpA2AUrqC5tXPFPwwOQ4eHAlCBcvo6odBxPTDAAAAWyFyVmRAAAE
AwBGMEQCIE3b0NIjT7zfIiP8TA+OztLmCl15ffubTHI6qeQP3lDrAiAJ7JDaFQg3
sdMhj1d3zen1Na4PSlDlLQX187L2bS1w9wB3AG9Tdqwx8DEZ2JkApFEV/3cVHBHZ
AsEAKQaNsgiaN9kTAAABbIXJXfIAAAQDAEgwRgIhAOm0Yz1QGdid5/mpfL/I+IBa
splzmI4VQSyN2DN8w+jQAiEAmKKJmhaIOQH36Wr83nB5FNKHRKimvycyJDNf33X0
uUEwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMIIBwQYDVR0gBIIBuDCC
AbQwggGcBg8rBgEEAYGoGAIBAYEqAgowggGHMCYGCCsGAQUFBwIBFhpodHRwOi8v
Y3AuZS1zemlnbm8uaHUvcWNwczB4BggrBgEFBQcCAjBsDGpRdWFsaWZpZWQgUFNE
MiBjZXJ0aWZpY2F0ZSBmb3Igd2Vic2l0ZSBhdXRoZW50aWNhdGlvbi4gVGhlIGNl
cnRpZmljYXRlIGlzIGFzc29jaWF0ZWQgd2l0aCBhbiBvcmdhbml6YXRpb24uMDMG
CCsGAQUFBwICMCcMJUV4dGVuZGVkIFZhbGlkYXRpb24gKEVWKSBjZXJ0aWZpY2F0
ZS4wcQYIKwYBBQUHAgIwZQxjTWluxZFzw610ZXR0IFBTRDIgd2Vib2xkYWwtaGl0
ZWxlc8OtdMWRIHRhbsO6c8OtdHbDoW55LiBBIHRhbsO6c8OtdHbDoW55IHN6ZXJ2
ZXpldGhleiBrYXBjc29sw7NkaWsuMDsGCCsGAQUFBwICMC8MLUZva296b3R0YW4g
ZWxsZW7FkXJ6w7Z0dCAoRVYpIHRhbsO6c8OtdHbDoW55LjAJBgcEAIGYJwMBMAcG
BWeBDAEBMB0GA1UdDgQWBBRZIBEFwBwvHyrXo9T5X0LiTdFQJjAfBgNVHSMEGDAW
gBR9hE7C1GvqwdcijGjD6aD07JiKHDAZBgNVHREEEjAQgg53d3cuc29mb3J0LmNv
bTCBtgYDVR0fBIGuMIGrMDegNaAzhjFodHRwOi8vcXRsc2NhMjAxOC1jcmwxLmUt
c3ppZ25vLmh1L3F0bHNjYTIwMTguY3JsMDegNaAzhjFodHRwOi8vcXRsc2NhMjAx
OC1jcmwyLmUtc3ppZ25vLmh1L3F0bHNjYTIwMTguY3JsMDegNaAzhjFodHRwOi8v
cXRsc2NhMjAxOC1jcmwzLmUtc3ppZ25vLmh1L3F0bHNjYTIwMTguY3JsMIIBXwYI
KwYBBQUHAQEEggFRMIIBTTAvBggrBgEFBQcwAYYjaHR0cDovL3F0bHNjYTIwMTgt
b2NzcDEuZS1zemlnbm8uaHUwLwYIKwYBBQUHMAGGI2h0dHA6Ly9xdGxzY2EyMDE4
LW9jc3AyLmUtc3ppZ25vLmh1MC8GCCsGAQUFBzABhiNodHRwOi8vcXRsc2NhMjAx
OC1vY3NwMy5lLXN6aWduby5odTA8BggrBgEFBQcwAoYwaHR0cDovL3F0bHNjYTIw
MTgtY2ExLmUtc3ppZ25vLmh1L3F0bHNjYTIwMTguY3J0MDwGCCsGAQUFBzAChjBo
dHRwOi8vcXRsc2NhMjAxOC1jYTIuZS1zemlnbm8uaHUvcXRsc2NhMjAxOC5jcnQw
PAYIKwYBBQUHMAKGMGh0dHA6Ly9xdGxzY2EyMDE4LWNhMy5lLXN6aWduby5odS9x
dGxzY2EyMDE4LmNydDAiBgVngQwDAQQZMBcTA1BTRBMCREUMDEJBRklOLTE1MTc4
ODCB+AYIKwYBBQUHAQMEgeswgegwCAYGBACORgEBMAsGBgQAjkYBAwIBCjBTBgYE
AI5GAQUwSTAkFh5odHRwczovL2NwLmUtc3ppZ25vLmh1L3FjcHNfZW4TAmVuMCEW
G2h0dHBzOi8vY3AuZS1zemlnbm8uaHUvcWNwcxMCaHUwEwYGBACORgEGMAkGBwQA
jkYBBgMwZQYGBACBmCcCMFswJjARBgcEAIGYJwECDAZQU1BfUEkwEQYHBACBmCcB
AwwGUFNQX0FJDCdGZWRlcmFsIEZpbmFuY2lhbCBTdXBlcnZpc29yeSBBdXRob3Jp
dHkMCERFLUJBRklOMA0GCSqGSIb3DQEBCwUAA4IBAQCFgo5udjz4onjjMyy4rvvP
ZkaMb0UnXqmZ1tyNSql8if15a6/H/GsXBvRhszUIUNUAS3W6mTpnQg5SvzqbPF2m
/TLXH8QfERr1mfLRZd4mPzwQzXWx1tavTJLGC920ozzxvC0juw8hAxdiAZsdUKL1
nEo9uoYKZL/tmatu/OyAraNO07F9V0WwdH3rAfTOADIFg5D9+PL0AT9XMU/mKLeO
65G/re5T3hIdu4Juig0zSM+6XxNdoEZtczn8SyY3hWDsGUHIKyjfAybl+beEN1Op
X8Ym21yzHkRS2Q6QJx31A85v3h3UqymmC307Dcs8Wb4DVKlXYf7KAcHsenDu7FpM
-----END CERTIFICATE-----

I have begun to review this request and have the following preliminary questions:

  • I am unable to locate the description of email address validation practices required by Mozilla policy section 2.2?
  • Which CP and CPS apply to S/MIME certificates?
  • CCADB currently lists 9 audit letter validation failures for Microsec. When will those be corrected, and if necessary, an incident filed?
Flags: needinfo?(szoke.sandor)
Whiteboard: [ca-cps-review] - KW 2019-02-12 → [ca-cps-review] - Pending CA response 22-Nov 2019

As part of the normal yearly audit process, Microsec has reviewed its public documents and issued the new version on 2019-09-25.
The new versions have already been uploaded to CCADB but I give the most important direct links here too.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.11.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.11.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.11.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.11.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.11.pdf

Flags: needinfo?(szoke.sandor)

(In reply to Wayne Thayer [:wayne] from comment #30)

I have begun to review this request and have the following preliminary questions:

  • I am unable to locate the description of email address validation practices required by Mozilla policy section 2.2?
    Our present CPS doesn't contain details about the email validation. We will add a new section into the next version which will be published on 2019-12-12.
    The brief description of our email validation process is:

Applicant can issue the Certificatete Request through our web page by filling out the application form.
Before entering the data the Applicant shall give his email address for verification purposes, all the other fields are disabled.
After receiving the email address Microsec automatically generates a unique, limited validity URL containing sufficient random part and sends it to the given email address.
The Applicant shall enter the received URL to be able to continue the Certificate request process.
This way all the received certificate applications are connected to a verified email address which can be included in the requested certificate or after the identity validation of the Applicant it can be used as a verified communication channel of the Applicant.

  • Which CP and CPS apply to S/MIME certificates?
    The S/MIME is not explicitly mentioned in our present public documents, but we can issue certificates for S/MIME purposes.
    We offer a pair of certificates, one for digital signature and the other for encryption. The Subject can be a natural person or a legal person, and due to the European legislation it needs different certificates, named signature for natural person and seal for legal persons.
    The digital signature certificates can be found in the following public documents:
    eIDAS conform Non-Qualified Electronic Signature Certificate Policies
    https://static.e-szigno.hu/docs/hr--fok--ala--EN--v2.11.pdf
    eIDAS conform Non-Qualified Certificate for Electronic Signature Certification Practice Statement
    https://static.e-szigno.hu/docs/szsz--fok--ala--EN--v2.11.pdf

eIDAS conform Non-Qualified Electronic Seal Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--bel--EN--v2.11.pdf
eIDAS conform Non-Qualified Certificate for Electronic Seal Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--bel--EN--v2.11.pdf

The encryption certificates are issued under the following public documents:
Non eIDAS covered Certificate Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--uni--EN--v2.11.pdf
Non eIDAS covered Certificates Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--uni--EN--v2.11.pdf

  • CCADB currently lists 9 audit letter validation failures for Microsec. When will those be corrected, and if necessary, an incident filed?
    We have checked the indicated failures, the answers are written into the CCADB.
    The problems can be classified into three categories.
    I could find a problem with the hash values of our root CA, it shall be checked in the CCADB.

In some certificates the problem may be caused by splitting the sha256 value into two pages. We will ask our auditor to always keep the sha256 hash value on the same page.

The third category is caused because in 2009 when we issued our new intermediate certificates we identified a problem with the key usage setting and a few months later we renewed the affected intermediate certificates.
To avoid any problems during the revocation check we haven't revoked the original intermediate certificates.

We discussed this situation with Kathleen in 2016 and added all the existing certificates for all or CAs to the CCADB. This is the reason why we have certificates with the same subject name, but only the latest one is used to issue enduser certificates and only that one is in the scope of the audit.
I include here the last emails for reference:

From: Kathleen Wilson <kwilson@mozilla.com>
Sent: Monday, November 14, 2016 6:33 PM
To: SZŐKE Sándor <szoke.sandor@microsec.hu>
Subject: Re: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs

Dear Sándor,

That is fine, as long as Mozilla's policy and the CA/Browser Forum Baseline Requirements are met, in regards to audits. Auditors typically will not audit intermediate certs that have not issued certs during the audit period, but they could at least verify that no TLS/SSL certs were signed by it during the audit period.

Best Regards,
Kathleen

On 11/14/16 8:17 AM, SZŐKE Sándor wrote:
Dear Kathleen,

we discussed the situation and we think that it would be better to leave those intermediate CA certificates in a valid state, because the revocation may cause problems for the customers.

I could successfully upload those certificates to the SalesForce and it accepted them without any problem.

They were live certificates for presently still operating intermediate CA-s, we issued end user certificates with them and those CA-s were audited in 2009.

We issued new intermediate certificates for those intermediate CA-s only because we recognized a problem in the CP field.
In the newer CA certificates we changed the CP value to „Any Policy” and the „Not Before” time were changed to the time of the issuance.
The CA key and the Issuer name is the same in the older and the newer certificates.

In the issued End user certificates there is no direct reference to a special issuing certificate, only the Issuer name included. Those intermediate certificates were published and still can be present in some (local) certificate stores. If we revoke them some user may think that the presently used intermediate certificates were revoked.

To avoid causing problem to our customers we would like to keep them in valid state. We can’t see a problem to have more than one valid certificate for the same Public Key and Issuer.

What is your opinion about this solution?

Best regards,

Sándor

(In reply to dr. Sándor SZŐKE from comment #32)

  • CCADB currently lists 9 audit letter validation failures for Microsec. When will those be corrected, and if necessary, an incident filed?
    We have checked the indicated failures, the answers are written into the CCADB.
    The problems can be classified into three categories.
    I could find a problem with the hash values of our root CA, it shall be checked in the CCADB.

In some certificates the problem may be caused by splitting the sha256 value into two pages. We will ask our auditor to always keep the sha256 hash value on the same page.

The third category is caused because in 2009 when we issued our new intermediate certificates we identified a problem with the key usage setting and a few months later we renewed the affected intermediate certificates.
To avoid any problems during the revocation check we haven't revoked the original intermediate certificates.

We discussed this situation with Kathleen in 2016 and added all the existing certificates for all or CAs to the CCADB. This is the reason why we have certificates with the same subject name, but only the latest one is used to issue enduser certificates and only that one is in the scope of the audit.
I include here the last emails for reference:

From: Kathleen Wilson <kwilson@mozilla.com>
Sent: Monday, November 14, 2016 6:33 PM
To: SZŐKE Sándor <szoke.sandor@microsec.hu>
Subject: Re: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs

Dear Sándor,

That is fine, as long as Mozilla's policy and the CA/Browser Forum Baseline Requirements are met, in regards to audits. Auditors typically will not audit intermediate certs that have not issued certs during the audit period, but they could at least verify that no TLS/SSL certs were signed by it during the audit period.

Best Regards,
Kathleen

On 11/14/16 8:17 AM, SZŐKE Sándor wrote:
Dear Kathleen,

we discussed the situation and we think that it would be better to leave those intermediate CA certificates in a valid state, because the revocation may cause problems for the customers.

I could successfully upload those certificates to the SalesForce and it accepted them without any problem.

They were live certificates for presently still operating intermediate CA-s, we issued end user certificates with them and those CA-s were audited in 2009.

We issued new intermediate certificates for those intermediate CA-s only because we recognized a problem in the CP field.
In the newer CA certificates we changed the CP value to „Any Policy” and the „Not Before” time were changed to the time of the issuance.
The CA key and the Issuer name is the same in the older and the newer certificates.

In the issued End user certificates there is no direct reference to a special issuing certificate, only the Issuer name included. Those intermediate certificates were published and still can be present in some (local) certificate stores. If we revoke them some user may think that the presently used intermediate certificates were revoked.

To avoid causing problem to our customers we would like to keep them in valid state. We can’t see a problem to have more than one valid certificate for the same Public Key and Issuer.

What is your opinion about this solution?

Best regards,

Sándor

All, It is the CA's responsibility to resolve old problems such as this. Things have changed since 2016, policies have changed, ability to identify problems and enforce policy have changed. CAs should have been keeping track of their own known problems in regards to not fully following the BRs and Mozilla policy and resolving them. I expect that a situation in which I responded with an OK in 2016 would have been corrected in the 3 years since that email was written. Email that I wrote back in 2016 should not be considered as granting anyone exceptions to following the BRs and Mozlla's root store policy in 2019.

Kathleen

Whiteboard: [ca-cps-review] - Pending CA response 22-Nov 2019 → [ca-cps-review] - Pending CPS updates 25-Nov 2019

Microsec has reviewed its public documents and issued the new version on the 2019-12-12.
The new versions have already been uploaded to CCADB (the update of the root CA data is in progress) but I give the most important direct links here too.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.12.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.12.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.12.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.12.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.12.pdf

We expect to have the new attestation letters tomorrow.

(In reply to dr. Sándor SZŐKE from comment #32)

(In reply to Wayne Thayer [:wayne] from comment #30)

I have begun to review this request and have the following preliminary questions:

  • I am unable to locate the description of email address validation practices required by Mozilla policy section 2.2?
    Our present CPS doesn't contain details about the email validation. We will add a new section into the next version which will be published on 2019-12-12.

The new policy documents that were published on 12/12 do not provide sufficient information in the change log to determine what was changed - it only states "Changes based on the suggestions of the auditor."

I am unable to locate a new section on email validation.

Even if I could locate this section, the documents that govern S/MIME certificates (where this information is required) were not updated.

The brief description of our email validation process is:

Applicant can issue the Certificatete Request through our web page by filling out the application form.
Before entering the data the Applicant shall give his email address for verification purposes, all the other fields are disabled.
After receiving the email address Microsec automatically generates a unique, limited validity URL containing sufficient random part and sends it to the given email address.
The Applicant shall enter the received URL to be able to continue the Certificate request process.
This way all the received certificate applications are connected to a verified email address which can be included in the requested certificate or after the identity validation of the Applicant it can be used as a verified communication channel of the Applicant.

Our auditor (TÜViT) has issued the new Attestation Letters for our non-EV services.
There are separate ALs for our existing root and for our new root. The ALs can be downloaded from the website of the auditor from the following links:
Microsec e-Szigno Root CA 2009
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_s.pdf

e-Szigno Root CA 2017
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_s.pdf

I have opened an Audit Update Case in the CCADB for the "Microsec e-Szigno Root CA 2009". I could not select the new root "e-Szigno Root CA 2017" so I added a comment into the open audit case.

(In reply to Wayne Thayer [:wayne] from comment #35)

(In reply to dr. Sándor SZŐKE from comment #32)

(In reply to Wayne Thayer [:wayne] from comment #30)

I am unable to locate a new section on email validation.

There is a new section in the CPS documents:
3.2.7 Email address validation

This new section is not included in the CP documents.

Even if I could locate this section, the documents that govern S/MIME certificates (where this information is required) were not updated.

We issued the new version for all type of the public documents and all CPS include this new section.
The following CPS documents are relevant for S/MIME users:

eIDAS conform Non-Qualified Certificate for Electronic Signature Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ala--EN--v2.12.pdf

eIDAS conform Non-Qualified Certificate for Electronic Seal Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--bel--EN--v2.12.pdf

The encryption certificates are issued under the following public document:
Non eIDAS covered Certificates Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--uni--EN--v2.12.pdf

(In reply to Wayne Thayer [:wayne] from comment #35)

(In reply to dr. Sándor SZŐKE from comment #32)

(In reply to Wayne Thayer [:wayne] from comment #30)

The new policy documents that were published on 12/12 do not provide sufficient information in the change log to determine what was changed - it only states "Changes based on the suggestions of the auditor."

Usually we have several changes in the public documents so the change log would be huge if we would give too much details about the change in case of each version. The log is mainly used to inform the users about the issuance date of the different versions and the comment contains only some very basic information.
All the earlier CP and CPS versions are available on our web page.

Microsec manages the public documents in a common LATEX source and the individual documents are generated from that source.
The tracking of the changes is not so easy than in case of a Word document, but Microsec manages the changes in the source by using special commands and upon request it is possible to generate working version of the documents which indicate the changes in the documents.

(In reply to dr. Sándor SZŐKE from comment #36)

Our auditor (TÜViT) has issued the new Attestation Letters for our non-EV services.
There are separate ALs for our existing root and for our new root. The ALs can be downloaded from the website of the auditor from the following links:
Microsec e-Szigno Root CA 2009
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_s.pdf

e-Szigno Root CA 2017
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_s.pdf

I have opened an Audit Update Case in the CCADB for the "Microsec e-Szigno Root CA 2009". I could not select the new root "e-Szigno Root CA 2017" so I added a comment into the open audit case.

The "Microsec e-Szigno Root CA 2009" with serial number 00C27E43044E473F18 still shows an ALV failure because it is not listed in the updated audit statement.

Flags: needinfo?(szoke.sandor)

The "Microsec e-Szigno Root CA 2009" root certificate exists in two versions, they are doppelganger certificates.
The original version contains the certificatePolicies extension and the later version doesn't.
We actively use and publish only the later version but both versions exist and valid.
We have already contacted our auditor to issue a new version of the Attestation Letter which contains both root CA certificate versions.

Flags: needinfo?(szoke.sandor)

(In reply to dr. Sándor SZŐKE from comment #40)

We have already contacted our auditor to issue a new version of the Attestation Letter which contains both root CA certificate versions.

Please update this bug when the new report has been submitted to CCADB.

Whiteboard: [ca-cps-review] - Pending CPS updates 25-Nov 2019 → [ca-cps-review] - Updated CP/CPS and Audit Statements Provided - ready for discussion

Microsec has reviewed its public documents and issued the new version on the 2020-03-05.
The new versions have already been uploaded to CCADB, but I give the most important direct links here too.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.13.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.13.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.13.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.13.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.13.pdf

Discussion period has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ

Whiteboard: [ca-cps-review] - Updated CP/CPS and Audit Statements Provided - ready for discussion → [ca-in-discussion] - 2020-03-09
Assignee: wthayer → bwilson

In accordance with my email of 28-May-2020 (see https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/yLTkQ25uAAAJ ), I'll review the Microsec CP/CPS.

Microsec has reviewed its public documents and issued the new version on the 2020-05-26.
The new versions have already been uploaded to CCADB, but I give the most important direct links here too.

The new public documents are available on the Microsec web site on the following links:

eIDAS conform Qualified Certificate for Website Authentication Certificate Policy
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.14.pdf

eIDAS conform Qualified Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.14.pdf

eIDAS conform Qualified Certificate for Website Authentication Disclosure Statement
https://static.e-szigno.hu/docs/kiv--min--ssl--EN--v2.14.pdf

eIDAS conform Non-Qualified Certificate for Website Authentication Certificate Policies
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.14.pdf

eIDAS conform Certificate for Website Authentication Certification Practice Statement
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf

While I am not holding up approval of the inclusion of this root for these reasons, Microsec should be aware of:

  • section 3.1.1 of Microsec's eIDAS conform Certificate for Website Authentication CPS (https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the CPS"). It appears to allow certain identifiers, but I don't believe that has been added to the Baseline Requirements, see https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/. This is something that should be taken up with the CA/Browser Forum; and
  • see section 4.9.5 of the CPS which states "Emails arriving out of office hours are considered as arrived at the beginning of the next business day." This may put Microsec at risk of a violation of the Baseline Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet defined in the Baseline Requirements, there is an expectation of 24x7 availability, which it appears Microsec has - "The Trust Service Provider maintains a continuous 24x7 ability to respond internally to a High Piority Certificate Problem Report."

This concludes my review of the Microsec CPs/CPSes, and I believe it is now appropriate to begin the process of adding this root CA into NSS (without EV enablement).

Flags: needinfo?(kwilson)

(In reply to Ben Wilson from comment #47)

While I am not holding up approval of the inclusion of this root for these reasons, Microsec should be aware of:

There is no any special ETSI requirement for "normal" TLS certificates, ETSI EN 319 412-4 V1.1.1 simply refers to the requirements of BR and EVG.
The only exception is the case of PSD2 TLS certificates, which issue was resolved by a new version of EVG last year.
The problematic field is the Organization Identifier (OrgID OID: 2.5.4.97).
It is a standard field defined by ITU-T X.520, but is not listed as a permitted field in Section 7.1.4.2.2 of the Baseline Requirements.
This does not mean that the use of this field is illegal, as BR explicitly allows the use of other subject attributes that are not listed in BR.
In the present Microsec CPS, it is an optional field and is usually not filled in by Microsec.
Microsec will review the CPS. At the moment, I don’t see any reason why we shouldn’t omit this field entirely from the next version of our CPS.

  • see section 4.9.5 of the CPS which states "Emails arriving out of office hours are considered as arrived at the beginning of the next business day." This may put Microsec at risk of a violation of the Baseline Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet defined in the Baseline Requirements, there is an expectation of 24x7 availability, which it appears Microsec has - "The Trust Service Provider maintains a continuous 24x7 ability to respond internally to a High Priority Certificate Problem Report."

Microsec offers Subscribers a number of options to revoke their certificates.
These options are described in CPS 4.9.3. Section. The deadlines for each method are described in CPS 4.9.5. Section.
Microsec processes SMS based requests and web-form based requests immediately 24 hours a day (7/24). The certificate will be revoked within a few minutes or the revocation request will be denied.
There are other revocation methods which are not "real-time" but may in many cases be more appropriate for subscribers.
These are electronic or paper-based, signed written revocation requests that can be sent to Microsec Customer Service through a variety of communication channels. These type of revocation requests are processed during normal office hours and processed within 24 hours of receipt of the revocation request, as described in the CPS.
So Microsec has 7/24 revocation service to solve urgent revocation requests, but also offers other possibilities where the 24 hours processing deadline is not guaranteed and is not needed.
From the comment, I see that the present description is not clear and can be misleading.
Microsec will review the CPS. Next version will provide more detailed and clearer information on the various options for submitting revocation requests, their availability and key parameters (like processing deadlines).

This concludes my review of the Microsec CPs/CPSes, and I believe it is now appropriate to begin the process of adding this root CA into NSS (without EV enablement).

The discussion period for this request has ended. I believe that all questions have been answered, so I am recommending approval of this request.
Link(s) to the discussion:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/MtFy9_dyCAAJ

(In reply to Ben Wilson from comment #49)

The discussion period for this request has ended. I believe that all questions have been answered, so I am recommending approval of this request.
Link(s) to the discussion:
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/MtFy9_dyCAAJ

To clarify, Ben is recommending approval of the request to include the e-Szigno Root CA 2017 certificate and enable the websites trust bit.

However, he has recommended that we deny the request for EV treatment for both root certificates. Microsec may re-apply
by filing a new request for EV treatment after they have demonstrated improved compliance with the BRs and EV Guidelines.

Reference: https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/yLTkQ25uAAAJ

Flags: needinfo?(kwilson)
Assignee: bwilson → kwilson
Whiteboard: [ca-in-discussion] - 2020-03-09 → [ca-pending-approval]

One more clarification: The request is to include the 2017 root with the websites and email trust bits enabled. I am not aware of any reason why the email trust bit should not also be enabled as part of this request.

Therefore, the approval that is pending is to include the e-Szigno Root CA 2017 certificate and enable the websites and email trust bits.

Reference: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
"This request is to include the 2017 root with the websites and email trust bits enabled, ..."

On behalf of Mozilla I approve this request from Microsec to include the following root certificate:

** 'e-Szigno Root CA 2017' (Email, Websites)

I will file the NSS bug for the approved change.

Whiteboard: [ca-pending-approval] → [ca-approved] - pending inclusion
Depends on: 1645174

I have filed bug #1645174 against NSS for the actual changes.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - pending inclusion → [ca-approved] - In NSS 3.54, FF 79
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: