火狐正在强制重新颁发数以千计的证书

他们回复称，意大利在这里的第#34；项下有效。如果Subject：Country Name字段根据第7.1.4.2.2(G)节规定了ISO 3166-1用户分配的代码XX，则Subject：stateOrProvinceName字段可以包含根据基准要求中第3.2.2.1."；节验证的主题国家信息的全名。

这似乎是对用户指定代码定义的系统性误解，我觉得可能会有更多的证书出现这个问题。

如果Subject：Country Name字段根据第7.1.4.2.2(G)节规定了ISO 3166-1用户分配的代码XX，则Subject：stateOrProvinceName字段可以包含根据第3.2.2.1节验证的主题国家/地区信息的全名。

在BR第7.1.4.2.2(F)和7.1.4.2.2(H)节中，'；XX'；不是占位符，而是一个逐字记录的国家/地区代码，ISO 3166-1将其指定为用户指定的国家/地区代码。用户指定的国家/地区代码是由用户赋予含义的代码，在标准中没有给定的含义/名称。要使在7.1.4.2.2(F)中发现的异常适用，需要Subject：Country Name=XX，而提供的批次不包括这样的证书。

如果Subject：OrganationName字段存在，则Subject：Country Name必须包含与根据3.2.2.1节验证的主题位置关联的两个字母的ISO 3166-1国家/地区代码。如果没有Subject：OrganationName字段，则Subject：Country Name字段可以包含与根据第3.2.2.3节验证的主题相关联的两个字母的ISO 3166-1国家/地区代码。如果某个国家不是由官方ISO 3166-1国家代码表示，CA可以指定ISO 3166-1用户分配的代码XX，表示尚未分配官方ISO 3166-1 alpha-2代码。

主题：Country Name中的ERGO，XX仅在国家/地区未分配ISO 3166-1国家代码时有效(意大利分配了一个国家代码：IT)。随后，只有这样，Subject：stateOrProvence字段才可以逐字包含国家名称(这可能是为了指示国家代码XX表示哪个国家)。

我还附上了另外429个叶证书指纹，这些指纹是在"；Italia"；的stateOrProvinceName字段中发现的。

首先，我们想重申，这个问题是由于对基线要求的误解造成的，因为没有明确禁止字段Subject：stateOrProvinceName的值。从我们的观点来看，需要重新措辞，以避免未来的误解。

目前，我们想通知您，有些证书是高级证书，我们不能在最后期限内替换和撤销它们。

当我们完成对该案例的完整研究后，我们将包括有关该问题的更多信息。

如果存在，Subject：stateOrProvinceName字段必须包含根据3.2.2.1节验证的主题的州或省信息。

您是否要在stateOrProvinceName字段中明确禁止国家/地区名称？就意大利而言，这一点似乎相当清楚，因为意大利不是一个省份。这些证书还包括localityName和OrganationName字段，因此不需要stateOrProvinceName字段。

为了呼应乔治的评论，我看不出一个人怎么能声称，鉴于这些证书，这是基线要求的模棱两可。

如果您不会像您在CP/CPS内公开承诺的那样撤销，并且这是信任Camerfirma的基础，则需要针对单独违反CA的CP/CPS和基准要求的情况单独发生事件。请确保在任何适当的截止日期和您的研究完成之前提交此类新事件，因为要继续信任CA，他们必须及时通知任何未能遵守基线要求的情况。简单地说你将忽略你的CP/CPS不是通知的合适替代品。

同样非常重要的是，现在这个问题已经被发现，Camerfirma不再为这个问题颁发任何证书。Camerfirma今日已就此问题颁发预认证--https://crt.sh/?id=3439396046.。

目前，我们想通知您，有些证书是高级证书，我们不能在最后期限内替换和撤销它们。

(在新的事件报告中)您能否指出您的CP(S)或BR#34；高级证书在哪些地方定义并在最后期限内免予吊销？此外，您似乎已经能够提前识别无法遵守BR的证书。你到底为什么要签发这些证书呢？故意计划破坏BRS是不太可信的。

乔治：从我们的观点来看，明确的禁令会使BR的文本更加清晰。我们知道此字段不是必填字段，我们也不必填写它，事实上，我们还有其他未使用此字段的SSLS配置文件。这个问题给了我们一个想法，那就是可能改进所有分会的简档审批，以协调简档。此外，我们想重申，“国家”一词在所有国家都不一样，在意大利，国家是国家的同义词，不是用来指省份的。

关于Ryan提到的撤销，我们将为延迟打开一个新的bug，给出更多关于原因和计划的细节，所以我们认为没有必要为我们的CPS或BR不遵守而打开bug，因为我们将撤销符合它们的证书。

关于颁发的预证书，我们正在努力停止发放这些证书，并更改配置文件，以消除该字段。

Paul：用“高级”这个术语，我们试图指的是影响大量域和机器的证书。很抱歉使用了这样一个令人困惑的术语。这类证书的吊销比其他情况更复杂，因为我们需要定义替换计划，涉及的人员和资源更多。那些类型的SSL和受影响的证书数量让我们认为5天的期限是不够的。我们尽量不影响客户的活动。我们需要他们的协作来替换SSL证书，然后才能吊销。很难解释为什么在没有安全问题的情况下，我们需要如此紧急地撤销。这是肯定的，我们没有破坏BR的意图。当然，我们从来没有考虑过签发任何违反CPS或BR的证书的可能性，这个问题是由于误解而非自愿的。

您需要先登录，然后才能对此错误进行评论或更改。