We respond you point by point: > Under "ANF Global Root CA": > > https://kerberosns.com/cloud > > EV certificate is not compliant with EV Guidelines: > > - missing mandatory serialNumber in subjectDN (see section 9.2.6) > > - are you sure that "JORGE CABRERA CLARISSO" is the legal name of the entity > as recorded by the the incorporating or registration agency? Other attributes > in the certificate imply that this is in fact a personal name > (givenName=JORGE, surname=CABRERA CLARISSO)
We will revoke that certificate and we will issue a new name of an entity whose data/information are clearer than the first one. > OCSP service behind "http://ocsp.anf.es/spain/AV"; when validating the > subscriber certificate sends useless certificates in the responses: > > - the issuer of the dedicated OCSP responder (the requester already has it, > since it is necessary to build the request) > > - the root certificate "ANF Global Root CA" (seriously?) > > That's 4.8k wasted on the wire for each response, approx. 70%. The reason to respond in that way is because it is possible to do OCSP queries from JAVA which you only need the certificate issuer, then it is advisable to include the entire chain. In addition, some OCSP users demand, for more security, to be included in the response chain OCSP. > Under "ANF Server CA": > > https://anf.kerberosns.com/en/ > > Nothing particular on the server certificate > > OCSP service behind "http://ocsp.anf.es/spain/AV"; when validating the > subscriber certificate has the same problems as mentioned (useless CA > certificates in the response), plus: > > - OCSP responder certificate is a 1024 bits one > > - OCSP responder certificate doesn't contain the OCSPNoCheck extension > > - OCSP responder certificate contains an empty CRLDP extension (forbidden by > definition); remove it, and add the OCSPNoCheck extension We understand the problem is that the certificate should be 2048. We will issue new certificates according to your comments. > Issuing certificate "ANF SSL Sede CA1" has the following problems: > > - the CRLDP is invalid; 3 URLS are concatenated, separated by a '\n' > character), one of them seems to be improperly constructed > (ldap://ldap.anf.es:389/cn=ANF_SSL_Sede_CA1.crl,ou=ANF_SSL_Sede_CA1,ou=ANF_Server_CA,dc=anf > should probably be > ldap://ldap.anf.es:389/cn=ANFServerCA_arl.crl,ou=ANF_Server_CA,dc=anf), while > the 2 others point to a CRL whose scope is reduced to user certificates, thus > not compatible with this CA certificate > > - the SAN extension contains an invalid "dNSName=http://www.anf.es"; entry > (this is a URI, not a DNS Name) > A new certificate will be issued considering your comments. > > OCSP service behind "http://www.anf.es/AC/RC/ocsp"; when validating the > issuing certificate has the same problems (useless CA certificates in the > response), plus: > > - OCSP responder certificate doesn't contain the OCSPNoCheck extension The same response as discussed above for certificates of OCSP, new OCSP certificates will be issued. > Root certificate contains useless extensions: > > - AIA:OCSP > > - CRLDP (pointing to a CRL valid for user certificates only) This was a recommendation from an important Korean software company, they require us to include the extensions to allow the interoperability with software from Ecuador and Panama. Including the extensions dont have to affect to the root certificate security. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
