Re: GlobalSign misissuance: 4 certificates with invalid CN
On Friday, May 17, 2019 at 10:11:55 PM UTC+1, Doug Beattie wrote: > All customers were migrated from this API > but the API was not disabled. >One of our custom on-premise applications was > misconfigured to use this old API. > This text in your mail seems to imply that customers were migrated away and that the remaining application was an internal application that was part of your estate. This is contradicted by the details in your bug report that states the application while provided by yourselves was used by a 3rd party and allowed them to issue certificates with unvalidated common names. 1. If it was possible for the customer to issue certificates with no technical control on the CN then what guarantees do you have that other certificates issued by this API were correctly validated? For example have you revalidated all such certificates? 2. What failures in process allowed an API that issues unvalidated certificates to be left in a usable state? How will these be addressed? 3. Do you have other deprecated but still usable APIs that allow issuance? (this is partly addressed by your comments in the ticket). Rich ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote: > > The expected distribution when generating a random 64 bit integer > and properly encoding that as DER is that: > - about 1/2 integers require 9 bytes > - about 1/2 integers require 8 bytes > - about 1/512 integers require 7 bytes > - about 1/131072 integers require 6 bytes > - about 1/33554432 integers require 5 bytes > - [...] > > That a serial is smaller than 8 bytes is not an indication that it > doesn't contain enough entropy. This is true, but the situation is surely worse - any CA who's serial numbers do not have a significant length variation is almost certainly not providing 64 bits of entropy with the exception of those who are add a prefix to ensure it is positive, and even those are not providing it unless they have lots of serial numbers with a big block of zeros. If any other CA wants to check theirs before someone else does, then now is surely the time to speak up. Kind Regards Rich ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
> the scope of the main project if ~120 certs across a similar number of > vendors. One of the home grown applications also hardcode the name of the > certificate into the application and will require not only certificate update > in coordination with the vendors but code changes on 120 certs in 12 days. It seems likely to me that these applications won't actually support OCSP and updating any CRLs in use may well be a manual process too. So, if the certificates were revoked, would your applications actually notice at all? It's quite different from them expiring which is coded into the certificate itself. Kind Regards Rich ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Trustico / Digicert Mass Revocation
This is likely to be of interest to people on this list. It sounds like a mass revocation with little detail as to why: https://www.reddit.com/r/sysadmin/comments/80uaq3/digicert_certificates_being_revoked/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs not compliant with CAA CP/CPS requirement
On 22 September 2017 at 17:22, Rob Stradling <rob.stradl...@comodo.com> wrote: > On 22/09/17 17:07, Richard Moore via dev-security-policy wrote: > >> I see, the one I saw in the wild was issued from the intermediate below >> and >> linked to the Gandi document however it was from 2014. That said, I don't >> see the intermediate in crt.sh though that could just be me failing to use >> the site properly! >> > > > That intermediate is https://crt.sh/?id=931 > > Thanks Rob Rich. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs not compliant with CAA CP/CPS requirement
I see, the one I saw in the wild was issued from the intermediate below and linked to the Gandi document however it was from 2014. That said, I don't see the intermediate in crt.sh though that could just be me failing to use the site properly! Cheers Rich. Certificate: Data: Version: 3 (0x2) Serial Number: 5a:b6:1d:ac:1e:4d:a2:06:14:c7:55:3d:3d:a9:b2:dc Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU= http://www.usertrust.com, CN=UTN-USERFirst-Hardware Validity Not Before: Oct 23 00:00:00 2008 GMT Not After : May 30 10:48:38 2020 GMT Subject: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b6:54:3d:a5:db:0d:22:78:50:6a:5a:23:89:3f: 97:a1:d4:07:1a:a9:58:08:9b:a0:15:c3:32:b6:b7: f1:e8:b9:a5:6f:ad:37:f6:6e:71:1b:b4:75:2d:48: 5e:9f:c6:15:aa:81:ef:e5:c4:88:95:8a:3a:6c:77: cc:b5:cd:65:e4:67:e5:73:c9:50:52:94:c1:27:49: 3e:a0:6b:41:16:41:b6:94:99:41:ae:3e:cb:e2:06: 46:09:e9:4d:be:c9:4c:55:a9:18:7e:a6:df:6e:fd: 4a:b2:cc:6c:4e:d9:c8:50:15:93:b3:f2:e9:e3:c2: 6a:ad:3a:d5:fb:c3:79:50:9f:25:79:29:b2:47:64: 7c:20:3e:e2:08:4d:93:29:14:b6:34:6e:cf:71:46: 7e:76:10:f4:fd:6c:aa:01:d2:c2:06:de:92:83:cc: 58:90:2e:92:de:1e:65:b7:63:2f:3d:b2:eb:70:8c: 4c:e0:be:15:9d:de:c1:4d:56:f8:0b:c6:8e:07:b9: 5d:df:95:f0:7b:40:1f:1a:2c:d7:9c:2b:4b:76:f4: 59:f5:43:c1:2c:66:10:9e:9e:66:96:60:9d:1c:74: 1b:4e:18:5c:08:b0:6e:6c:ca:69:1a:02:e9:bb:ca: 78:ef:66:2e:e3:32:fd:41:5c:95:74:81:4d:f4:da: fe:4b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45 X509v3 Subject Key Identifier: B6:A8:FF:A2:A8:2F:D0:A6:CD:4B:B1:68:F3:E7:50:10:31:A7:79:21 X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6449.1.2.2.26 X509v3 CRL Distribution Points: Full Name: URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl Authority Information Access: CA Issuers - URI: http://crt.usertrust.com/UTNAddTrustServer_CA.crt OCSP - URI:http://ocsp.usertrust.com Signature Algorithm: sha1WithRSAEncryption 19:53:bf:03:3d:9b:e2:6b:5a:fd:ba:49:1f:4f:ec:e1:c6:82: 39:3c:d2:03:04:0f:ab:7b:3e:82:a9:85:10:1f:f4:de:32:af: 58:3f:ff:70:f3:30:1d:97:2d:4c:9a:e2:ec:0c:3e:14:2d:2f: 98:48:9d:ae:16:6a:ac:2d:42:aa:b5:64:a4:70:bb:eb:73:94: 7b:46:4c:e7:7a:14:76:5b:4c:1d:84:a1:20:74:1f:2e:4b:5c: 70:88:dc:bd:f7:19:3d:ed:59:0d:e2:3f:26:e2:9c:ac:a4:3c: 95:1c:f8:be:8c:03:ae:f0:e5:9c:4d:bc:c7:9b:58:00:bf:af: ad:fa:37:6e:71:6d:18:34:0e:c1:ea:6a:f8:0d:df:69:54:56: 15:f2:28:b3:fe:a4:63:ec:c5:04:64:60:bb:fe:2a:f0:f4:87: a1:b0:ae:bd:aa:e4:2f:e3:03:0b:2f:66:5f:85:a4:32:7b:46: ed:25:0c:e7:f1:b7:e7:19:fd:60:ba:5f:87:77:de:98:07:96: e4:5e:ea:63:7d:a8:de:55:da:61:5c:3c:90:83:43:04:07:3c: dd:f3:f8:9f:06:52:0a:de:c7:b6:7b:8f:e1:11:f7:04:7a:35: ff:6a:bc:5b:c7:50:49:08:70:6f:94:43:cd:9e:c7:70:f1:db: d0:6d:da:8f -BEGIN CERTIFICATE- MIIEozCCA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt SGFyZHdhcmUwHhcNMDgxMDIzMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBBMQswCQYD VQQGEwJGUjESMBAGA1UEChMJR0FOREkgU0FTMR4wHAYDVQQDExVHYW5kaSBTdGFu ZGFyZCBTU0wgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2VD2l 2w0ieFBqWiOJP5eh1AcaqVgIm6AVwzK2t/HouaVvrTf2bnEbtHUtSF6fxhWqge/l xIiVijpsd8y1zWXkZ+VzyVBSlMEnST6ga0EWQbaUmUGuPsviBkYJ6U2+yUxVqRh+ pt9u/UqyzGxO2chQFZOz8unjwmqtOtX7w3lQnyV5KbJHZHwgPuIITZMpFLY0bs9x Rn52EPT9bKoB0sIG3pKDzFiQLpLeHmW3Yy89sutwjEzgvhWd3sFNVvgLxo4HuV3f lfB7QB8aLNecK0t29Fn1Q8EsZhCenmaWYJ0cdBtOGFwIsG5symkaAum7ynjvZi7j Mv1BXJV0gU302v5LAgMBAAGjggE+MIIBOjAfBgNVHSMEGDAWgBShcl8mGyiYQ5Vd BzfVhZadS9LDRTAdBgNVHQ4EFgQUtqj/oqgv0KbNS7Fo8+dQEDGneSEwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEE AbIxAQICGjBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5j
