1119091 - sec_error_expired_issuer_certificate

Status: RESOLVED INCOMPLETE

(Core :: Security: PSM, defect)

Description

[maokexu2011]

Attachment: 图片2.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

1、安装证书
2、浏览证书所对应的网址
3、提示证书已经过期
注：在google ie浏览器是正常的。


Actual results:

提示证书已经过期


Expected results:

直接和google浏览器一样，验证通过。

Comment 1

[:Gijs (he/him)]

YF, can you help translating / explaining this? Thank you!

Comment 2

[YF (Yang)]

I was seen this problem on https://www.firefox.net.cn/read-50143, but I don't understand it.

He has a private domain root certificate (expired), it will released certificates of several ports. He hope to add a generic exception for certificates of multiple ports of same domain. He said that is normal in IE and Chrome (Not confirmed).

Comment 3

[YF (Yang)]

to maokexu2011: 在这个Bugzilla请尽量使用英文。能否提供在操作系统的证书管理器中的该根证书的截图/导出文件。你确定它的有效时间是已过期的吗？

Comment 4

[maokexu2011]

English:
the root certificate is in Attachments .

chinese:
根证书在附近当中。

thanks!

Comment 5

[maokexu2011]

Attachment: 图片21.png

this is root certfication.

Comment 6

[maokexu2011]

Attachment: 图片23.png

this is certificate.

Comment 7

[maokexu2011]

Attachment: 图片22.png

this is certificate

Comment 8

[maokexu2011]

thank you.
I provide the certificate.
If I install the personal certificate,
I hope certificate verification by the fire browser same as Google browser.

Comment 9

[maokexu2011]

I think the essence of problem is  the self-signed certificate validation issues.
This problem happen only in fire browser.
My English is poor, please forgive me.
thank you!

Comment 10

[:Gijs (he/him)]

It sounds like the issue is that the self-signed root (issuer) cert is expired - that's certainly what the error says. If the request is to allow exceptions for expired self-signed roots, that sounds like wontfix to me, but I defer to dkeeler and other domain experts.


The not being able to add exceptions in one go for all ports (storing exceptions per-cert instead of per host+port) is a separate issue. It's not clear to me which of them this bug is about (or if it's supposed to be both). Can either of you (YF/maokexu) clarify?

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Yes, unconditionally allowing exceptions for expired self-signed roots is probably not something we're going to do (although it should still be possible to add exceptions on an origin-by-origin basis). I'll be able to say more about what's probably going on here with a copy of the actual certificates in question.

Comment 12

[maokexu2011]

Attachment: 图片24.png

问题：
关于 https://bugzilla.mozilla.org/show_bug.cgi?id=1119091
目前我仍看不出具体原因，请提供一下出错时的【已了解风险-添加例外】对话框的“详细信息”截图，是只有一个证书，还是有上层颁发者。
另外，建议在详细信息面板中，依次选择每个证书、导出按钮，把证书发过来看看，结构还是没看明白，是否真的有过期的颁发者。
提醒，“对等端的证书已被用户标记为不受信任”的错误是因为导入证书的步骤有错误，应该勾选“网站”那个复选框。可以“编辑信任”修改一下。

-- 
Best regards, 
YFdyh000.

回答：
详细信息为图片23，只有一个证书;网站,已经选择。

Comment 13

[maokexu2011]

(In reply to :Gijs Kruitbosch from comment #10)
> It sounds like the issue is that the self-signed root (issuer) cert is
> expired - that's certainly what the error says. If the request is to allow
> exceptions for expired self-signed roots, that sounds like wontfix to me,
> but I defer to dkeeler and other domain experts.
> 
> 
> The not being able to add exceptions in one go for all ports (storing
> exceptions per-cert instead of per host+port) is a separate issue. It's not
> clear to me which of them this bug is about (or if it's supposed to be
> both). Can either of you (YF/maokexu) clarify?

 only a certificate, issued by the upper;In Google chrome, the certificate is ok.
 the detail is in Attachment 8551143 [details].

Comment 14

[maokexu2011]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #11)
> Yes, unconditionally allowing exceptions for expired self-signed roots is
> probably not something we're going to do (although it should still be
> possible to add exceptions on an origin-by-origin basis). I'll be able to
> say more about what's probably going on here with a copy of the actual
> certificates in question.
Actually the certificate has not expired, can in the Google browser, is proof of that.

Comment 15

[:Gijs (he/him)]

(In reply to maokexu2011 from comment #13)
> (In reply to :Gijs Kruitbosch from comment #10)
> > It sounds like the issue is that the self-signed root (issuer) cert is
> > expired - that's certainly what the error says. If the request is to allow
> > exceptions for expired self-signed roots, that sounds like wontfix to me,
> > but I defer to dkeeler and other domain experts.
> > 
> > 
> > The not being able to add exceptions in one go for all ports (storing
> > exceptions per-cert instead of per host+port) is a separate issue. It's not
> > clear to me which of them this bug is about (or if it's supposed to be
> > both). Can either of you (YF/maokexu) clarify?
> 
>  only a certificate, issued by the upper;In Google chrome, the certificate
> is ok.
>  the detail is in Attachment 8551143 [details].

Please attach the actual certificates instead of screenshots from the certificate viewer.

Comment 16

[YF (Yang)]

“导出”它并上传为附件以便检查原因。

Comment 17

[maokexu2011]

Attachment: www.center140.com.44846.crt

I have attached the actual certificates.
have a look please.

Comment 18

[YF (Yang)]

(In reply to maokexu2011 from comment #17)
> Created attachment 8551545 [details]
> www.center140.com.44846.crt
> 
> I have attached the actual certificates.
> have a look please.

Good.

Perhaps this is because:
https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes 
End-entity certificates used in SSL/TLS servers:
    Are not allowed to have basic constraints asserting isCA=TRUE.

Comment 19

[maokexu2011]

(In reply to YF (Yang) from comment #18)
> (In reply to maokexu2011 from comment #17)
> > Created attachment 8551545 [details]
> > www.center140.com.44846.crt
> > 
> > I have attached the actual certificates.
> > have a look please.
> 
> Good.
> 
> Perhaps this is because:
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-
> testing#Behavior_Changes 
> End-entity certificates used in SSL/TLS servers:
>     Are not allowed to have basic constraints asserting isCA=TRUE.

Can say clear some? I still don't understand.
How to solve it?

Comment 20

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

That certificate includes the x509v3 "basic constraints" extension with the value "ca = true". This means that that certificate can issue other certificates. In general, this is not something we want website certificates to be able to do (for example, if a certificate were issued for "attacker.com", we don't want that certificate to be able to then issue a certificate for "victim.com"). The easiest way to fix this would be to re-create that certificate but without the basic constraints extension. This page might be useful in setting up a certificate hierarchy: https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates

Comment 21

[maokexu2011]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #20)
> That certificate includes the x509v3 "basic constraints" extension with the
> value "ca = true". This means that that certificate can issue other
> certificates. In general, this is not something we want website certificates
> to be able to do (for example, if a certificate were issued for
> "attacker.com", we don't want that certificate to be able to then issue a
> certificate for "victim.com"). The easiest way to fix this would be to
> re-create that certificate but without the basic constraints extension. This
> page might be useful in setting up a certificate hierarchy:
> https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates

thanks a lot.
My basic understand what you mean.
But I need that certificate can issue other certificates.
What should I do?
[root@www test]# certtool -i --infile /etc/pki/certs/cacert.pem
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 1000
        Issuer: C=US,O=center.com,CN=www.center.com.96062
        Validity:
                Not Before: Mon Nov 17 08:13:32 UTC 2014
                Not After: Fri Nov 15 08:13:32 UTC 2024
        Subject: C=US,O=center.com,CN=www.center.com.96062
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        d1:ad:........
                        d6:b2:........
                        ......
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Subject Key Identifier (not critical):
                        8cde6884f0c2....
                Authority Key Identifier (not critical):
                        8cde6884f0c28....
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Key Usage (critical):
                        Certificate signing.
                        CRL signing.
        Signature Algorithm: RSA-SHA
        Signature:
                77:db:ef:a4:98:fa:f5:24:a3:86:6d:bd:e6:36:4b:38
                .........
Other Information:
        MD5 fingerprint:
                78bef68ad6b..
        SHA-1 fingerprint:
                befd4984af39...
        Public Key Id:
                b1aeac20388...
[root@www test]# certtool --generate-certificate \
>              --template host1_server_template.info \
>              --load-privkey host1_server_key.pem \
>              --load-ca-certificate cacert.pem \
>              --load-ca-privkey cakey.pem \
>              --outfile host1_server_certificate.pem
Generating a signed certificate...
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 54.....
        Validity:
                Not Before: Wed Dec 17 08:02:13 UTC 2014
                Not After: Thu Dec 17 08:02:13 UTC 2015
        Subject: O=center.com,CN=www.server1.com
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        9d:c9:ea:b1...........
                        .......
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                        270631e......
                Authority Key Identifier (not critical):
                        8cde6884.....
Other Information:
        Public Key Id:
                270631e....



Signing certificate...

Comment 22

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I may have misunderstood - if attachment 8551545 [details] is your root certificate, then having basic constraints: ca = true is fine (and in fact necessary). Can you post the entire certificate chain the server in question is sending? It may also help to see host1_server_template.info.

Comment 23

[maokexu2011]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #22)
> I may have misunderstood - if attachment 8551545 [details] is your root
> certificate, then having basic constraints: ca = true is fine (and in fact
> necessary). Can you post the entire certificate chain the server in question
> is sending? It may also help to see host1_server_template.info.
I hope certificate verification by the fire browser same as Google browser.
In Google chrome, the certificate is ok.
host1_server_template.info:
[root@www test]# more host1_server_template.info
organization = center.com
cn = www.server1.com
signing_key
encryption_key
tls_www_client
tls_www_server
expiration_days = 700

Comment 24

[maokexu2011]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #22)
> I may have misunderstood - if attachment 8551545 [details] is your root
> certificate, then having basic constraints: ca = true is fine (and in fact
> necessary). Can you post the entire certificate chain the server in question
> is sending? It may also help to see host1_server_template.info.

[root@www test]# certtool -i --infile host1_server_certificate.pem 
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 54913885
        Issuer: C=US,O=center.com,CN=www.center.com.96062
        Validity:
                Not Before: Wed Dec 17 08:02:13 UTC 2014
                Not After: Thu Dec 17 08:02:13 UTC 2015
        Subject: O=center.com,CN=www.server1.com
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        9d:c9:ea:b1:73:bc:1d:56:76:f1:47:a2:e0:bd:de:3b
                        ...................
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                        2706.....
                Authority Key Identifier (not critical):
                        8cd.....
        Signature Algorithm: RSA-SHA
        Signature:
                cb:5c:15:e9:e2:f1:70:f0:c4:be:0c:df:26:42:22:59
                ....
Other Information:
        MD5 fingerprint:
                7abc97e...................
        SHA-1 fingerprint:
                82a27a48...................
        Public Key Id:
                27......................

-----BEGIN CERTIFICATE-----
MIIDaDCCAlKgAwIBAgIEVJE4hTALBgkqhkiG9w0BAQUwQTELMAkGA1UEBhMCVVMx
.....................................
gIIn8OS7oWtygwgj
-----END CERTIFICATE-----

Comment 25

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

What would really be helpful is if you could attach the file host1_server_certificate.pem to this bug (that's the public part of the certificate and shouldn't have any private information in it).

Comment 26

[maokexu2011]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #25)
> What would really be helpful is if you could attach the file
> host1_server_certificate.pem to this bug (that's the public part of the
> certificate and shouldn't have any private information in it).
These can be?
[root@www test]# certtool -i --infile host1_server_certificate.pem 
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 54913885
        Issuer: C=US,O=center.com,CN=www.center.com.96062
        Validity:
                Not Before: Wed Dec 17 08:02:13 UTC 2014
                Not After: Thu Dec 17 08:02:13 UTC 2015
        Subject: O=center.com,CN=www.server1.com
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        9d:c9:ea:b1:73:bc:1d:56:76:f1:47:a2:e0:bd:de:3b
                        3e:40:d1:34:b5:d5:5e:0d:b3:71:19:2e:d5:65:b0:48
                        a2:e0:14:f6:32:ea:49:d6:04:e0:23:a6:0a:1b:49:c9
                        19:29:94:48:7a:ec:9c:b9:a7:4b:25:e1:cb:86:5f:ec
                        8c:ce:1e:6e:44:bd:df:73:cd:78:a5:96:3e:1b:12:d5
                        b7:20:1c:59:fb:e6:9e:78:e8:2e:ed:8b:00:35:8f:ed
                        e9:4b:2e:18:b6:45:4e:54:3b:bf:08:d8:78:f4:97:7e
                        ad:dc:cd:82:43:56:39:ee:d0:d6:25:73:35:ff:7d:08
                        e6:84:69:44:18:ff:04:12:98:71:5a:26:50:d7:3b:d8
                        25:a0:eb:99:9b:93:c7:e6:91:12:28:c3:a2:21:60:ee
                        d2:14:e3:85:54:64:8d:a8:81:12:8e:f2:cf:9b:db:63
                        51:15:6d:18:7a:b7:74:67:b3:51:c5:65:56:dd:29:2e
                        07:31:10:b0:be:9f:d9:8e:9a:a2:a7:32:b9:66:58:ab
                        5c:2f:9a:05:b5:a0:ae:51:e4:97:c5:78:a6:f0:2e:cd
                        8d:93:fe:92:51:0e:ba:bf:75:be:84:0f:4e:7d:8b:b5
                        de:a1:cc:56:da:ea:ce:16:c6:e7:bf:dc:f4:88:6d:d9
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                        270631ef4d1da84de91e50cfa3e5b388109f1477
                Authority Key Identifier (not critical):
                        8cde6884f0c283c6b67bb2cc5c632918ad5d0979
        Signature Algorithm: RSA-SHA
        Signature:
                cb:5c:15:e9:e2:f1:70:f0:c4:be:0c:df:26:42:22:59
                b6:c8:16:1c:1c:9f:09:cd:43:d5:9e:9a:5f:8a:a0:fc
                86:ae:17:5e:ac:ef:0a:3e:2d:41:87:65:4f:af:90:22
                f8:d4:02:81:fe:56:79:17:db:ed:b7:3d:68:c5:33:0f
                68:d4:4e:72:ce:7a:8c:4d:bf:5d:ab:68:39:8f:ec:0d
                ba:b4:b1:c1:5d:a1:ff:48:90:25:06:a9:c2:07:99:34
                63:f8:cc:27:d8:c3:78:a7:93:a3:ca:b8:f6:3d:6e:f2
                05:5f:da:00:1c:bc:04:fb:2c:24:af:d2:b3:22:bf:8e
                48:2e:a1:94:ab:9d:d5:13:f8:73:c4:d9:f7:a4:79:a3
                8b:e6:c7:21:d8:5d:8e:5e:c2:b3:d4:36:d2:bd:a2:e6
                4f:4b:ab:1f:04:c7:f6:36:ef:54:96:0a:2b:2f:f8:d2
                22:7e:e5:30:77:e3:95:e3:55:02:49:27:d9:6c:8b:18
                b8:bb:12:d3:3c:91:09:f3:7f:a2:6b:05:f1:3e:e8:32
                06:50:8d:54:09:28:8c:99:e8:d0:86:cd:21:d2:7b:a8
                4a:e5:62:d1:c8:1e:9a:2c:a5:7a:44:42:62:e2:2a:f7
                88:50:bf:9f:80:82:27:f0:e4:bb:a1:6b:72:83:08:23
Other Information:
        MD5 fingerprint:
                7abc97e5....
        SHA-1 fingerprint:
                82a27a489...
        Public Key Id:
                270631ef4...

-----BEGIN CERTIFICATE-----
MIIDaDCCAlKgAwIBAgIEVJE4hTALBgkqhkiG9w0BAQUwQTELMAkGA1UEBhMCVVMx
EzARBgNVBAoTCmNlbnRlci5jb20xHTAbBgNVBAMTFHd3dy5jZW50ZXIuY29tLjk2
MDYyMB4XDTE0MTIxNzA4MDIxM1oXDTE1MTIxNzA4MDIxM1owLzETMBEGA1UEChMK
Y2VudGVyLmNvbTEYMBYGA1UEAxMPd3d3LnNlcnZlcjEuY29tMIIBHzALBgkqhkiG
9w0BAQEDggEOADCCAQkCggEAncnqsXO8HVZ28Uei4L3eOz5A0TS11V4Ns3EZLtVl
sEii4BT2MupJ1gTgI6YKG0nJGSmUSHrsnLmnSyXhy4Zf7IzOHm5Evd9zzXillj4b
EtW3IBxZ++aeeOgu7YsANY/t6UsuGLZFTlQ7vwjYePSXfq3czYJDVjnu0NYlczX/
fQjmhGlEGP8EEphxWiZQ1zvYJaDrmZuTx+aREijDoiFg7tIU44VUZI2ogRKO8s+b
22NRFW0Yerd0Z7NRxWVW3SkuBzEQsL6f2Y6aoqcyuWZYq1wvmgW1oK5R5JfFeKbw
Ls2Nk/6SUQ66v3W+hA9OfYu13qHMVtrqzhbG57/c9Iht2QIDAQABo4GAMH4wDAYD
VR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDwYDVR0P
AQH/BAUDAwegADAdBgNVHQ4EFgQUJwYx700dqE3pHlDPo+WziBCfFHcwHwYDVR0j
BBgwFoAUjN5ohPDCg8a2e7LMXGMpGK1dCXkwCwYJKoZIhvcNAQEFA4IBAQDLXBXp
4vFw8MS+DN8mQiJZtsgWHByfCc1D1Z6aX4qg/IauF16s7wo+LUGHZU+vkCL41AKB
/lZ5F9vttz1oxTMPaNROcs56jE2/XatoOY/sDbq0scFdof9IkCUGqcIHmTRj+Mwn
2MN4p5Ojyrj2PW7yBV/aABy8BPssJK/SsyK/jkguoZSrndUT+HPE2fekeaOL5sch
2F2OXsKz1DbSvaLmT0urHwTH9jbvVJYKKy/40iJ+5TB345XjVQJJJ9lsixi4uxLT
PJEJ83+iawXxPugyBlCNVAkojJno0IbNIdJ7qErlYtHIHpospXpEQmLiKveIUL+f
gIIn8OS7oWtygwgj
-----END CERTIFICATE-----

Comment 27

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

It looks like the public key for that certificate is encoded incorrectly. Since the most significant byte has its most significant bit set, it needs a leading '00' byte to indicate that it is a positive number, not a negative number. If you regenerate the certificate with a valid encoding, does it work? (Also, I apologize for taking so long to get back to this.)