Details
-
Type:
Bug
-
Status: Closed
-
Priority:
High
-
Resolution: Fixed
-
Affects Version/s: 5.7.1
-
Fix Version/s: None
-
Component/s: TLS
-
Labels:None
-
Sprint:2018 - S7, 2018 - S8
-
Account:Maintenance 2018 (MAINTENANCE2018)
Description
If the application(s) validating the certificates is(are) aligned with version 2.2.2 of the Certificate profile requirements, it should not raise any error from the three "error messages" mentioned below and copied here:
1. The DName MUST have only one OU.
2. BasicConstraints MUST be included as a critical extension in the certificate.
3. BasicConstraints MUST always be designated as critical in the certificate (fund it as non critical).
These are not requirements from version 2.2.2 of the Certificate Profile document. So this should be a non-issue.
The same applies for most of the warnings raised:
· T-Systems allows issuing certificates of 12, 24 or 36 months by default (or 1, 2 or 3 years); a different term of x months can be administered by agreement. The certificate validity is set when the master domain is set up and is passed on to the areas of responsibility (sub-domains). Within the master domain, no differing validity periods are possible for certificates with the same name. The current certificates are issued with 3 years validity but it is only a "should", a recommendation surely but no strong requirement. It may be checked whether this can be configured at eHealth sub-domain level.
· E SHOULD NOT be provided: no such requirement in v2.2.2
· L SHOULD NOT be provided: no such requirement in v2.2.2
· SERIALNUMBER SHOULD NOT be provided: no such requirement in v2.2.2
· IssuerAlternativeName SHOULD be included as a non-critical extension in the certificate: no such requirement in v2.2.2 ("may" is used not even "should")
· If [SubjectAltNames] is used, E-Mail addresses (RFC822-name) [RFC 822] MAY also be made available: this is the case so why raising such a warning?
· CertificatePolicies SHOULD be included as an extension in the certificate to include the eHealth DSI certificate policy identifier: 1.3.130.0.2017.ARES_number_of_the_present_document. This is not the case but the eHealth DSI certificate policy identifier is included in one of the OU attributes of the Subject DN, and actually is a document reference from 2018 (OU=NCP_PPT-GTC_OID-1.3.130.0.2018.996911 in the tested certificate)
1. The DName MUST have only one OU.
2. BasicConstraints MUST be included as a critical extension in the certificate.
3. BasicConstraints MUST always be designated as critical in the certificate (fund it as non critical).
These are not requirements from version 2.2.2 of the Certificate Profile document. So this should be a non-issue.
The same applies for most of the warnings raised:
· T-Systems allows issuing certificates of 12, 24 or 36 months by default (or 1, 2 or 3 years); a different term of x months can be administered by agreement. The certificate validity is set when the master domain is set up and is passed on to the areas of responsibility (sub-domains). Within the master domain, no differing validity periods are possible for certificates with the same name. The current certificates are issued with 3 years validity but it is only a "should", a recommendation surely but no strong requirement. It may be checked whether this can be configured at eHealth sub-domain level.
· E SHOULD NOT be provided: no such requirement in v2.2.2
· L SHOULD NOT be provided: no such requirement in v2.2.2
· SERIALNUMBER SHOULD NOT be provided: no such requirement in v2.2.2
· IssuerAlternativeName SHOULD be included as a non-critical extension in the certificate: no such requirement in v2.2.2 ("may" is used not even "should")
· If [SubjectAltNames] is used, E-Mail addresses (RFC822-name) [RFC 822] MAY also be made available: this is the case so why raising such a warning?
· CertificatePolicies SHOULD be included as an extension in the certificate to include the eHealth DSI certificate policy identifier: 1.3.130.0.2017.ARES_number_of_the_present_document. This is not the case but the eHealth DSI certificate policy identifier is included in one of the OU attributes of the Subject DN, and actually is a document reference from 2018 (OU=NCP_PPT-GTC_OID-1.3.130.0.2018.996911 in the tested certificate)
