1391066 - SwissSign: Non-BR-Compliant Certificate Issuance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case. 

** Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

Comment 1

[Corneia Enke]

We have contacted our customer, which in the meantime has replaced and revoked the non-conformant certificate.
At the moment SwissSign is implementing technical measures to avoid such an error in the future.

The Certificate was revoked on Aug 7, 

https://crt.sh/?q=D72C6D18B580BE0170F2F976B480D783FC5F6E17

Mechanism   Provider    Status            Revocation Date   Last Observed in CRL    Last Checked (Error)
CRL         The CA      Not Revoked       n/a               n/a                     2017-08-10  07:22:27 UTC
            

We have checked with CRL and OCSP and both report the certificate as revoked:

Response verify OK
0x6951563C82C60CCECC8E114ADAA41949C8DF784C: revoked
      This Update: Aug 10 06:06:27 2017 GMT
      Next Update: Aug 13 06:06:27 2017 GMT
      Reason: unspecified
      Revocation Time: Aug  7 14:19:10 2017 GMT

Serial Number: 6951563C82C60CCECC8E114ADAA41949C8DF784C
        Revocation Date: Aug  7 14:19:10 2017 GMT

Comment 2

[Ryan Sleevi]

Thanks for responding. I think it's still necessary to provide additional detail.

That is, we can look at the problem from two dimensions: The problem itself, and the systemic issues that allowed the problem to manifest. Your description focuses on the resolution of the problem, but doesn't indicate any systemic changes have been made. As a consequence, it does not help the community feel that your CA has taken steps to reduce the risk of future violations (of any requirement) in the future. That is, one dimension is "Did you fix the bug", but another dimension is "How was the bug introduced, why was it not detected, and what steps are you taking to prevent future bugs"

To understand how you might approach this problem, consider https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ and how it provided a timeline of events, the steps that were already in place (and with substantial detail), where there were controls missing or mistakes made, details about the steps being taken (e.g. "We fixed the bug" is not sufficient detail to understand), and a holistic, systemic awareness of how the CA is managed and the opportunities for errors.

In this particular case:
- What technical measures is SwissSign implementing?
- What technical measures already existed?
- Why were those technical measures insufficient?
- What steps is SwissSign taking to ensure all of its technical measures, independent of this, are sufficient?
- Please provide sufficient detailed answers to requests 3-6.

Comment 3

[Gervase Markham [:gerv]]

Also, please explain if you believe your Problem Reporting Mechanism is working as advertised. While it is not required that you respond to the reporter within 24 hours, that is a good practice we might expect.

Gerv

Comment 4

[Jonathan Rudenberg]

SwissSign does not have a problem reporting channel listed in the CCADB, and I was unable to find one on their website or in their CPS.

Comment 5

[Jonathan Rudenberg]

While investigating errors parsing a SwissSign CRL, it was discovered that SwissSign has issued at least five certificates with negative serial numbers. RFC 5280 section 4.1.2.2 says:

> CAs MUST force the serialNumber to be a non-negative integer.

These are the only leaf certificates with negative serial numbers that are unexpired, trusted by NSS and known to CT.

https://misissued.com/batch/14/

https://crt.sh/?id=10735365&opt=cablint
https://crt.sh/?id=10881592&opt=cablint
https://crt.sh/?id=10746284&opt=cablint
https://crt.sh/?id=10985276&opt=cablint
https://crt.sh/?id=11670463&opt=cablint

Comment 6

[Corneia Enke]

On behalf of Reihard Detrich wissSIgn CISO
===============


Dear Kathleen, Ryan, Gervase and Jonathan,

thank you for your input. As dedicated CISO  I want to answer to your helpful hints:

First of all Gervase is completely right: we became aware of the first problem of SAN/subject disharmony at August 7th and missed to communicate directly to you due to the holiday absence. As Gervase said this is a good practise and should be the policy of SwissSign in this context and as future CISO of this company I will mandate this.
Let me further answer to Jonathans hint concerning the incident messages for invalid certificates.
Our homepage: www.swisssign.com shows a FAQ concerning the steps to do in case of detection of an invalid certificate (the own one or a third party certificate):
https://www.swisssign.com/en/catalogsearch/result/?q=invalidity 
We publish this FAQ in English, German and French on https://www.swisssign.com/en/faq . Also people visiting our page www.swisssign.net will be addressed to the collection of FAQs round revocation and contact our incident team in case of invalid certificates by clicking on the main menu field “Revoke certificate”.  Our first level support screens continuously our incoming incidents and categorize and prioritize them. Invalid certificates and certificates to be revoked tickets will be immediately tracked by our operations staff as urgent tickets. Regarding Jonathans suggestion we realized that the information only in the FAQ is not enough and that we have to expand the general “contact form” (https://www.swisssign.com/en/contact) page by a special content topic (revocation and invalid certificate incident). This software change to this page will become effective in the beginning of next week. Additionally we will also review and optimize the information in our mentioned FAQ.

Let me answer your questions according to the bullet points Kathleen mentioned here. We will start with the first, original mentioned bug (Subject-SAN: “juratronic.ch.” – “juratronic.ch”) and with the same bullet points again for the second bug of the negative serial numbers.

1)How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.

The thread of the policy group was read first by our team member at August 7th, in the morning. It showed that the certificate mentioned below did not meet the requirements and there was a difference between the name in the subject (“juratronic.ch.”) and the SAN name (“juratronic.ch”, without dot).
Our incident team came together and quickly decided to take the following measures:
a)	Subscriber will be informed immediately by phone
b)	New (correct) certificate will be issued for the customer
c)	Certificate will be revoked and 
d)	Setup communication with Mozilla Forum (which was apparently not done)
e)	Immediate start of investigation in the CA software to prevent follow-up mistakes of this kind
f)	Creating of an analysis script to detect similar issues not detected by cablint
g)	Analysis if there are more certificates misissued with the same type of faults
h)	Setup communication with the auditor
i)	Incorporation of this test pattern for our release tests
Results:
a)	At August 7th, 11.42 am local time (UTC 9.42 am) the subscriber was informed.
b)	At August 7th, 3.23 am local time (UTC 1.23 am) the subscriber got its new certificate
c)	At August 7th, 4.19 pm local time (UTC 2.19 am) the certificate was revoked
d)	Communication was prepared but not sent – due to lookup of the Mozilla Report in the inbox of the person in holiday and unclear communication afterwards.
e)	Software error was detected and implementation was started (August 7th). It was at least the dot char (“.”) which made a problem. Internal tests are now setup and roll-out is planned for September 5th. Meanwhile we monitor that there is no additional certificate with the same problem issued.
f)	An analysis script was developed (August 8th) to find similar problems (see below)
g)	We did not detect any further fault
h)	Auditor information was prepared and will be sent out today
i)	Adaptation of our test automation framework with this test case has been started


2)Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
The issuance of certificates with the mentioned problem will be technically constrained with the new software release at September 2nd.

3)Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
We checked in special the problem of discrepancies between SAN and subject entry. In this case we could not detect any further occurrence. 

But our script detected also certificates with discrepancies according to the usage of A-Label vs. U-Label. We will investigate this and probably address a software change ensuring that only punycode (A-Label) is in use.
Script output example – we found 3 occurencies:

<Serial number> - <Issuing CA> - <valid from> - <Subject CN> - <SAN entry>
3685D482F7BBFEC434B2E1BDDE79DC9C69DCD19D   
Server Silver G22   20160622080509    www.علاجتساقطالشعر.com   DNS:www.xn--mgbaakj7alkzoi8huai.com;DNS:xn--mgbaakj7alkzoi8huai.com
6C003906AC3A91F2A80577C92BFCCF32A225364C   
Server Silver G22   20160621080021    www.alopécie.com   DNS:www.xn--alopcie-eya.com;DNS:xn--alopcie-eya.com
274AFE9507ACA55FF6217913396ADEE90D145CCB   
Server Silver G22   *.wäckerlin.ch   DNS:*.xn--wckerlin-0za.ch;DNS:xn--wckerlin-0za.ch

During the analysis of this phenomena we found that Censys.io (https://censys.io/certificates/e1b2847a10599f1303da58667a873e4b73dbdf18755224e7e41d601d1c2fdea7/zlint) shows it as “bug” and crt (https://crt.sh/?id=16076138&opt=cablint,x509lint) does not mention it as a “bug” but rather as a “warning”. In addition this topic was also mentioned by Jonathan in the “Bugzilla Bugs re CA issuance of non-compliant certs” at August 15th. We will analyse it further.


4)Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.

<Serial number> - <Issuing CA> - <valid from> - <Subject CN> - <SAN entry>
6951563C82C60CCECC8E114ADAA41949C8DF784C   Server Gold G22   20170421130650    *.juratronic.ch.   DNS:*.juratronic.ch;DNS:juratronic.ch

The certificate was issued in April, 2017 and revoked on August 7th.


5)Explanation about how and why the mistakes were made, and not caught and fixed earlier.
The software contained a regex treatment which did not treat correctly the dot. Unfortunately our automated test framework did not cover this test case until now. This is fixed now and will be rolled out at Sept. 2nd.

6)List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
Software change for correct treatment of “.”,
Internal tests with the software change running till Sept. 2nd, 2017
Meanwhile manual observation of all issued certificates till Sept. 2nd, 2017
Roll-Out of the tested new CA version at Sept. 2nd
Tests on the productive CA version after Sept 2nd based on SwissSign owned domains.
Addressing the Unicode harmonization.
Each issued certificate will be checked by cablint functionality. Implementation of the adaptation of our compliance framework is in progress.

7)Regular updates to confirm when those steps have been completed.
We will inform you again on Sept 2nd of the successful roll-out of the new version.



We now want to inform about the 4 certificates containing negative serial numbers:

1)How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
Following the release launch at the end of 2015, we identified at January 15th, 2016 approximately 40 negative serial numbers. We then contacted the customers immediately to ensure the exchange of the certificates. On January 27th , 2016, we had informed all browser manufacturers about this incident.

2)Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
January 16th , 2016 a software fix was applied and since then only TLS/SSL certificates with positive serial numbers were issued.

3)Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
Still 5 certificates were not revoked as mentioned by Jonathan:
https://crt.sh/atom?umzugsoffice.ch 
https://crt.sh/atom?q=www.gateway-junior.net
https://crt.sh/atom?q=*.amicus.ch 
https://crt.sh/atom?q=Parl.ch 
https://crt.sh/atom?q=www.cosycard.ch 

4)Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
All certificate owners were requested in January 2016 along with the other detected certificates to exchange their certificate. In the case of the monitoring of the exchange, we now have to conclude that in five cases the exchange was not carried out. 
We now revoked four of them immediately today. The 5th (https://crt.sh/atom?q=www.cosycard.ch) will be revoked on Monday.

5)Explanation about how and why the mistakes were made, and not caught and fixed earlier.
Concerning monitoring of the exchange, we now have to conclude that in five cases the exchange was not carried out completely. The organizational setup has failed in this case.


6)List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Recently the new organization of the complete senior management of SwissSign was announced and will put into force in October 2017. Compliance and Security now has its own department and the head of this department is now part of the senior management team. With now dedicated resources only for security and compliance tasks the team will monitor all implementation measures of SwissSign. By application of this strategy we ensure to proactively avoid a repeated occurrence.

7)Regular updates to confirm when those steps have been completed.
Next update will happen on Monday concerning the last certificate to revoke.
.


Best Regards 
Reinhard Dietrich

Comment 7

[Corneia Enke]

Dear forum members

In addition to the precedent information we would like to inform you that

a) the last outstanding certificate with a negative serial number is revoked: 
   https://crt.sh/atom?q=www.cosycard.ch 
   revoked: 2017-08-22 12:55:24
   Serial number: #e956edb5e1005282bb6cfebffaf73d
   SHA1 Fingerprint: E0:66:2B:48:72:FB:AF:99:67:65:1B:9F:E9:BB:76:49:6B:52:8E:79
   SHA2 Fingerprint: EE:03:34:46:D2:AD:AC:B2:54:19:EA:54:5F:99:E3:98:11:39:DE:85:22:3D:B5:DE:EC:09:03:78:D5:4E:91:42

b) we added a special menu item in our contact form to communicate mis-issued or malformed certificates.

As outlined before we will keep you updated about the new release roll-out in September preventing further issues of certificates with a mismatch SAN-subject.

In case of any question please do not hesitate to contact us here.

Best Regards 
Reinhard Dietrich

Comment 8

[Ryan Sleevi]

(In reply to Corneia Enke from comment #6)
> Regarding Jonathans suggestion we realized that the information only in the
> FAQ is not enough and that we have to expand the general “contact form”
> (https://www.swisssign.com/en/contact) page by a special content topic
> (revocation and invalid certificate incident). 

The issue here is ensuring that Mozilla and the CCADB community have accurate and maintained information on how to report issues, as this is broadly used by the Mozilla/CCADB-using community for reporting problems.

At present, Mozilla Policy does not mandate any particular method, other than that it be disclosed.

Based on the publicly available information from CCADB ( https://ccadb-public.secure.force.com/mozilla/CAInformationReport ) and SwissSign's answer to Question 12 in the April 2017 communication ( https://wiki.mozilla.org/CA/Communications#April_2017_Responses ), this has not been captured in CCADB.

Kathleen: My understanding is this requires direct (non-CA) updating, correct? Is it possible to update this to reflect the above answer.

> Let me answer your questions according to the bullet points Kathleen
> mentioned here. We will start with the first, original mentioned bug
> (Subject-SAN: “juratronic.ch.” – “juratronic.ch”) and with the same bullet
> points again for the second bug of the negative serial numbers.
> 
> 1)How your CA first became aware of the problems listed below (e.g. via a
> Problem Report, via the discussion in mozilla.dev.security.policy, or via
> this Bugzilla Bug), and the date.
> 
> The thread of the policy group was read first by our team member at August
> 7th, in the morning. It showed that the certificate mentioned below did not
> meet the requirements and there was a difference between the name in the
> subject (“juratronic.ch.”) and the SAN name (“juratronic.ch”, without dot).
> Our incident team came together and quickly decided to take the following
> measures:
> a)	Subscriber will be informed immediately by phone
> b)	New (correct) certificate will be issued for the customer
> c)	Certificate will be revoked and 
> d)	Setup communication with Mozilla Forum (which was apparently not done)
> e)	Immediate start of investigation in the CA software to prevent follow-up
> mistakes of this kind
> f)	Creating of an analysis script to detect similar issues not detected by
> cablint
> g)	Analysis if there are more certificates misissued with the same type of
> faults
> h)	Setup communication with the auditor
> i)	Incorporation of this test pattern for our release tests
> Results:
> a)	At August 7th, 11.42 am local time (UTC 9.42 am) the subscriber was
> informed.
> b)	At August 7th, 3.23 am local time (UTC 1.23 am) the subscriber got its
> new certificate
> c)	At August 7th, 4.19 pm local time (UTC 2.19 am) the certificate was
> revoked
> d)	Communication was prepared but not sent – due to lookup of the Mozilla
> Report in the inbox of the person in holiday and unclear communication
> afterwards.
> e)	Software error was detected and implementation was started (August 7th).
> It was at least the dot char (“.”) which made a problem. Internal tests are
> now setup and roll-out is planned for September 5th. Meanwhile we monitor
> that there is no additional certificate with the same problem issued.
> f)	An analysis script was developed (August 8th) to find similar problems
> (see below)
> g)	We did not detect any further fault
> h)	Auditor information was prepared and will be sent out today
> i)	Adaptation of our test automation framework with this test case has been
> started

Thanks for responding with this detail. This is the expected plan for potential misissuance of all CAs, and is a positive sign that it was adopted - even if there were issues.

Without wanting to ascribe blame or fault, as our goal is to help improve the processes rather than blame individuals, it's useful to know what steps, if any, you've taken regarding Step D to ensure future communications go out in time.

For example, a 'playbook' is a common approach, much like in critical security systems, in which a standard process is developed and two-or-more parties review each step of the list to ensure it's completed. That helpfully adds redundancy and quality control to the process, without ascribing individual blame or fault.

> But our script detected also certificates with discrepancies according to
> the usage of A-Label vs. U-Label. We will investigate this and probably
> address a software change ensuring that only punycode (A-Label) is in use.
> Script output example – we found 3 occurencies:
> 
> <Serial number> - <Issuing CA> - <valid from> - <Subject CN> - <SAN entry>
> 3685D482F7BBFEC434B2E1BDDE79DC9C69DCD19D   
> Server Silver G22   20160622080509    www.علاجتساقطالشعر.com  
> DNS:www.xn--mgbaakj7alkzoi8huai.com;DNS:xn--mgbaakj7alkzoi8huai.com
> 6C003906AC3A91F2A80577C92BFCCF32A225364C   
> Server Silver G22   20160621080021    www.alopécie.com  
> DNS:www.xn--alopcie-eya.com;DNS:xn--alopcie-eya.com
> 274AFE9507ACA55FF6217913396ADEE90D145CCB   
> Server Silver G22   *.wäckerlin.ch  
> DNS:*.xn--wckerlin-0za.ch;DNS:xn--wckerlin-0za.ch
> 
> During the analysis of this phenomena we found that Censys.io
> (https://censys.io/certificates/
> e1b2847a10599f1303da58667a873e4b73dbdf18755224e7e41d601d1c2fdea7/zlint)
> shows it as “bug” and crt (https://crt.sh/?id=16076138&opt=cablint,x509lint)
> does not mention it as a “bug” but rather as a “warning”. In addition this
> topic was also mentioned by Jonathan in the “Bugzilla Bugs re CA issuance of
> non-compliant certs” at August 15th. We will analyse it further.

Thank you for detecting and proactively reporting these. We'll leave this bug open to address the follow-up of your investigation. Given that the use of Unicode in the CN can bypass browser security controls (bypassing browsers display policies or using inconsistent policies), I would encourage you to proactively consider revoking and reiussing these, and look forward to a timeline that may allow that transition to happen smoothly. Modern browsers will detect the A-Label to display as a U-label in a manner consistent with their security policies, and will reduce ambiguity as to the compliance.

> 6)List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future, accompanied with a timeline of
> when your CA expects to accomplish these things.
> Software change for correct treatment of “.”,
> Internal tests with the software change running till Sept. 2nd, 2017
> Meanwhile manual observation of all issued certificates till Sept. 2nd, 2017
> Roll-Out of the tested new CA version at Sept. 2nd
> Tests on the productive CA version after Sept 2nd based on SwissSign owned
> domains.
> Addressing the Unicode harmonization.
> Each issued certificate will be checked by cablint functionality.
> Implementation of the adaptation of our compliance framework is in progress.

Note that you can also execute cablint prior to the issuance of a certificate

https://groups.google.com/d/msg/mozilla.dev.security.policy/oTQ9OYgS8D4/KRFUWERDAgAJ documents the modifications necessary, and while it provides a crt.sh API, you can implement this within your own system. You create the tbsCertificate (as you would sign), then include the intended algorithm ID as the final signature (signatureAlgorithm), and a null signature (e.g. zero length signature). Happy to discuss further if that's useful.

> 7)Regular updates to confirm when those steps have been completed.
> We will inform you again on Sept 2nd of the successful roll-out of the new
> version.

Sounds good. I think we will consider the DNS issue closed at this time, and look for further follow-up on the Unicode issue mentioned within.

> 5)Explanation about how and why the mistakes were made, and not caught and
> fixed earlier.
> Concerning monitoring of the exchange, we now have to conclude that in five
> cases the exchange was not carried out completely. The organizational setup
> has failed in this case.
> 
> 
> 6)List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future, accompanied with a timeline of
> when your CA expects to accomplish these things.
> 
> Recently the new organization of the complete senior management of SwissSign
> was announced and will put into force in October 2017. Compliance and
> Security now has its own department and the head of this department is now
> part of the senior management team. With now dedicated resources only for
> security and compliance tasks the team will monitor all implementation
> measures of SwissSign. By application of this strategy we ensure to
> proactively avoid a repeated occurrence.

This sounds like a positive change, although again, we're not necessarily wanting to ascribe blame. As a design, it sounds like you've primarily changed responsibilities - but it's opaque as to how that will address some of the natural, understandable human errors that are involved in such systems.

From a procedures and policy point, can you share details about how/if the policies or procedures will change? Understandably, there's always the chance that "Someone didn't follow procedures", but even in that case, it can be informative to explore how it was possible for 'just one' person to not follow procedures. Or, if it's a department not following procedures, how it wasn't detected.

These are attempts to approach the underlying issue, as best as possible - and sharing information about how those practices are being developed, both to inform best practice and be informed of best practices, so that collectively, the ecosystem can improve :)

Comment 9

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #8)
> (In reply to Corneia Enke from comment #6)
> > Regarding Jonathans suggestion we realized that the information only in the
> > FAQ is not enough and that we have to expand the general “contact form”
> > (https://www.swisssign.com/en/contact) page by a special content topic
> > (revocation and invalid certificate incident). 
> 
> The issue here is ensuring that Mozilla and the CCADB community have
> accurate and maintained information on how to report issues, as this is
> broadly used by the Mozilla/CCADB-using community for reporting problems.
> 
> At present, Mozilla Policy does not mandate any particular method, other
> than that it be disclosed.
> 
> Based on the publicly available information from CCADB (
> https://ccadb-public.secure.force.com/mozilla/CAInformationReport ) and
> SwissSign's answer to Question 12 in the April 2017 communication (
> https://wiki.mozilla.org/CA/Communications#April_2017_Responses ), this has
> not been captured in CCADB.
> 
> Kathleen: My understanding is this requires direct (non-CA) updating,
> correct? Is it possible to update this to reflect the above answer.

Correct, I will update it for the CA for now. It has also been added to the Audit Case, so that CAs may review/update it annually.

However, It's not clear to me what I should put as the Problem Report Mechanism for this CA. I just checked https://www.swisssign.com/en/contact and I was not able to find the special content topic for revocation and invalid certificate incident.

Comment 10

[Ryan Sleevi]

The following items remain outstanding:
- A plan for the Unicode name transition & revocation (if revocation will be done) or explanation for why not
- Understanding how the policies/procedures have changed or additional controls and 'checks' to address the issue and/or mitigate future issues

Comment 11

[Corneia Enke]

(In reply to Ryan Sleevi from comment #10)
> The following items remain outstanding:
> - A plan for the Unicode name transition & revocation (if revocation will be
> done) or explanation for why not

With the next release (R4.9, rollout on 4 November 2017), we plan to allow only A-Label IDN with SSL certificates in the CN.

The three certificates found so far are to be exchanged and revoked after release 4.9.
If further certificates are found in our investigations, these certificates are also replaced and revoked


> - Understanding how the policies/procedures have changed or additional
> controls and 'checks' to address the issue and/or mitigate future issues

Compliance and Security now has its own department and the head of this department is now part of the senior management team. With now dedicated resources only for security and compliance tasks the team will monitor all implementation measures of SwissSign. By application of this strategy we ensure to proactively avoid a repeated occurrence.

At the Moment we are in the process of reviewing and impooving or current concept.

Comment 12

[Corneia Enke]

(In reply to Kathleen Wilson from comment #9)
> However, It's not clear to me what I should put as the Problem Report
> Mechanism for this CA. I just checked https://www.swisssign.com/en/contact
> and I was not able to find the special content topic for revocation and
> invalid certificate incident.


Based on your Feedback we have improved again the contact form. 


https://www.swisssign.com/en/contact

in the first row (TOPIC) click in the menu item, then you can scroll down and choose 
"Notification on incorrectly issued certificate"

Comment 13

[Kathleen Wilson]

Updated in CCADB.

Please also respond to Comment #10.

Comment 14

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #13)
> Please also respond to Comment #10.

Ooops. I see you already did in Comment #11.

Comment 15

[Ryan Sleevi]

Below is my noted summary of all issues and remediation plans:

1) Metadata-only subject fields
- See Comment #0
  - https://crt.sh/?id=81011860&opt=cablint
- Not yet addressed

2) Common Name not in SAN
- See Comment #1, Comment #6
- Remediation:
  - 2017-08-07 - Analysis run over existing certificates
  - 2017-08-07 - Manual monitoring began
  - 2017-09-05 - Technical controls to be deployed
  - 2017-09-05 - Additional test cases to be added to test suite

3) A-Label v U-Label within Common Name
- Identified in Comment #6 as part of the Remediation for issues in #2
- See Comment #6, Comment #11
- Remediation:
  - 2017-11-04 - Revocation planned for existing certificates
  - 2017-11-04 - New issuance platform (R4.9) to be deployed to only allow A-labels in commonName

4) Negative Serial Numbers
- See Comment #5, Comment #6
- Remediation:
  - 2016-01-16 - Updated software deployed to enforce positive serial numbers
  - 2017-08-22 - All existing negative serial numbers are to be revoked
  - 2017-08-22 - Restructuring of Compliance and Security to provide direct reporting and supervision, to allow independent oversight of revocation activities


Is that a complete summary?

Comment 16

[Corneia Enke]

Hello Ryan,

yes thats a correct summary. I want to address the point you mentioned: 

1) Metadata-only subject fields
Also with the next release (R4.9, rollout on 4 November 2017), we plan to fix the OU entry - the relevant certificate will be replaced after the release.

I will provide evidence about the affected certificates.

Best Regards Conny

Comment 17

[Ryan Sleevi]

Can you please provide an update whether the technical controls from #2 were deployed?
Are you still on track for the platform for #3?

Comment 18

[Reinhard Dietrich]

As announced below the  release 4.9 was rollout on 4 November 2017 and our monitoring has until now no further issues detected. The replacement of the relevant certificate is  not yet finished, we will upate  you after this work is done.

In addition our work to correct #3 is on track, but not finished.

Comment 19

[Ryan Sleevi]

Hi Reinhard:

It's unclear from your reply whether or not the technical controls were deployed and the additional test cases added on 2017-09-05 as proposed and outlined in comment #15. It would appear based on Comment #18 that you're suggesting they won't actually be deployed until 2017-11-04. Could you clarify?

Comment 20

[Reinhard Dietrich]

Hi

With the deployment of the release 4.9 we have introduce the announced technical controls, in addition we have added additional test-cases in our automated test-suite in the SW –development-process.

I hope this clarifies the open questions

Reinhard

Comment 21

[Ryan Sleevi]

Hi Reinhard - I'm still confused - I'm trying to understand the timeline of changes being planned, as the mix of past tense with future dates (e.g. Comment #18 - was rollout on 4 November 2017) leaves me unclear whether the action was completed or still remains to be completed.

I understand that this is part of version 4.9. It's unclear if version 4.9 has been released and is what you're running.

Comment 22

[Reinhard Dietrich]

@ Sleevi Thanks for your remark

The release I was talking about was the 4.8 release deployed at 5.September, sorry about the confusion I made

The release 4.8 has addressed the issue “difference between the name in the subject” E.g. (“juratronic.ch.”) and the SAN name (“juratronic.ch”, without dot).

Release 4.9 will addressed the issues about “A-Label v U-Label within Common Name” and “Metadata-only subject fields”

I hope I could now clarify the situation about the timeline

Reinhard

Comment 23

[Ryan Sleevi]

OK. So the technical controls for #1 in Comment #15 were deployed on 2017-09-05 (as part of 4.8), and the technical controls for #2 will be deployed on 2017-11-04 (as part of 4.9). I'm updating the bug accordingly.

Comment 24

[Reinhard Dietrich]

Thanks for your response

To be precise:

the technical controls for #2 in comment #15 were deployed on 2017-09-05 (as part of 4.8), and the technical controls for #1, #3 in comment #15 will be deployed on 2017-11-04 (as part of 4.9).

Comment 25

[Corneia Enke]

To whom it may concern,

On 4th November 2017 SwissSign released a new version of its software which has resolved the two outstanding issues relating to OU metadata (#0) and encoding differences between the /CN and the SAN (#2, #6, #11).

OU only contains metadata:
If an OU entry contains the characters ".", ",", and "-" only, then that OU entry is removed from the request and certificate.

A-Label v U-Label within Common Name : IDN2008 only in SSL
In SSL certificates only IDN (internationalised domain name) coded domains are included in the /CN and SAN.  This conversion is performed in the request UI.
We have five affected certificates remaining and these will be replaced shortly. We will post notice here as soon as the renewals have taken place.

Encoding Error:
/CN=www.xn--mgbaakj7alkzoi8huai.com
CerID: 3685D482F7BBFEC434B2E1BDDE79DC9C69DCD19D
Validity: 2016-06-22 08:05:09 bis 2019-06-22 08:05:09
 
/CN=www.alopécie.com
CerID: 6C003906AC3A91F2A80577C92BFCCF32A225364C
Validity: 2016-06-21 08:00:21 bis 2019-06-21 08:00:21
 
/CN=*.wäckerlin.ch
CertID: 274AFE9507ACA55FF6217913396ADEE90D145CCB
Validity: 2016-04-01 07:45:15 bis 2019-04-01 07:45:15
 
CertID: C46F4E23365318DFB95D6FBA84E75C
Validity: 2012-11-15 15:49:41 bis 2017-11-15 15:49:41
 
Metadata Information 
/CN=radon.eversys.ch
CertID: 6D2F479835B907DE28783BCF6AD8A0467F92C7DD
Validity: 2018-01-27


Best Regards 
Cornelia Enke
SwissSign AG

Comment 26

[Corneia Enke]

Final comment:

all the relevant certificates are revoked on November 30th 2017.

/CN=www.xn--mgbaakj7alkzoi8huai.com
CerID: 3685D482F7BBFEC434B2E1BDDE79DC9C69DCD19D
Validity: 2016-06-22 08:05:09 bis 2019-06-22 08:05:09
 
/CN=www.alopécie.com
CerID: 6C003906AC3A91F2A80577C92BFCCF32A225364C
Validity: 2016-06-21 08:00:21 bis 2019-06-21 08:00:21
 
/CN=*.wäckerlin.ch
CertID: 274AFE9507ACA55FF6217913396ADEE90D145CCB
Validity: 2016-04-01 07:45:15 bis 2019-04-01 07:45:15
 
 
Metadata Information 
/CN=radon.eversys.ch
CertID: 6D2F479835B907DE28783BCF6AD8A0467F92C7DD
Validity: 2018-01-27

This certificate is expired: 

/CN=*.wäckerlin.ch
CertID: C46F4E23365318DFB95D6FBA84E75C
Validity: 2012-11-15 15:49:41 bis 2017-11-15 15:49:41

From our point of view the issues adressed in this Bug are resolved.

Best Regards
Cornelia Enke