SHA2 “incomplete path” bug may have returned in USG1100 V4.31(AAPK.0)?
I installed a certificate from COMODOCA which seemed to work; but, I tried various combinations of the intermediate and root certificates without success.
From USG1100 firmware release notes:
Modifications in V4.11(AAPK.0)C0 - 2015/03/12
...
32.[BUG FIX] eITS#141000951
When using for SHA256 as intermediate certificate, the certificate path will shows “incomplete path”.
...
Since SHA1 is going away, this will be a major problem.
From USG1100 firmware release notes:
Modifications in V4.11(AAPK.0)C0 - 2015/03/12
...
32.[BUG FIX] eITS#141000951
When using for SHA256 as intermediate certificate, the certificate path will shows “incomplete path”.
...
Since SHA1 is going away, this will be a major problem.
0
Accepted Solution
-
I started focusing on the intermediate/root mistrust and tried a few things with OCSP; and, I think I found the solution to the problem -- and an issue with OCSP on the USG.
Background: Unlike most servers and clients, Zyxel devices apparently do not seem know about the existence of public CAs -- they MUST have a Self-Signed root. The public CAs are issuing certificates based on Cross-Signed roots which would technically make them intermediates; but they work with the most common servers and clients built-in trust anchors.
The original root cert I was trying to use was one of those Cross-Signed root certificates which the USG seems to trust because it looks like a root; but, the intermediate did not validate because the USG did not trust the chain...because the USG does not check with any external CAs.
After contacting ComodoCA(issuer of our cert), they were able to provide an alternate Self-Signed root certificate; the USG really trusted this cert as it validated the intermediate which in turn validated our certificate.
Note, both chains validate with OCSP using OpenSSL; but, the USG has an OCSP validation error.I left OCSP turned off.
0
All Replies
-
Hi @nnadmin,The root and intermediate CA should be imported to “Trusted Certificates” page, and server CA should be imported to “My Certificates” page.If the original file contains multiple CA, use the following steps or use tool to extract CA.Step 1. Import CA(double click CA file) on Windows PCStep 2. Go to browser (IE/Chrome) certificate setting to export root/intermediate/server CA from the storeLocationStep 3. Import root and intermediate CA file to to “Trusted Certificates”, and import server CA to “My Certificates” on ZyWALL.If you still have difficulty importing certificate, please send us the certificate and we can help you import certificate to USG1100.0
-
The problem is not importing the certificates; the problem is that after being imported, the USG doesn't follow the path of the chain upstream -- the only SHA2 certs it will trust are roots. First I used the original set of intermediates provided with our specific certificate; then I tried a few others and roots that were available on the Comodo website; none of the SHA2 type are followed by the USG -- resulting in a "incomplete path" indication. I have never had any problems getting a USG to trust SHA1 certs made by our own private CA; but, now we have some people outside of our organization we want to trust the cert -- hence the public CA issued certificate. Note, that public CAs are now issuing SHA2 certs with SHA2 chains up to the roots. Also, since about 2010, it has been bad practice to require importing and then presenting the actual root of public CAs; software is supposed to have a regularly updated root store embedded; and since all the certs are signed indirectly by intermediates, the roots can be properly validated by the clients.
0 -
Hi @nnadmin,
Thanks for the detailed description. We need the certificate to further check this issue.
I will send you the private message with the required information.
0 -
I started focusing on the intermediate/root mistrust and tried a few things with OCSP; and, I think I found the solution to the problem -- and an issue with OCSP on the USG.
Background: Unlike most servers and clients, Zyxel devices apparently do not seem know about the existence of public CAs -- they MUST have a Self-Signed root. The public CAs are issuing certificates based on Cross-Signed roots which would technically make them intermediates; but they work with the most common servers and clients built-in trust anchors.
The original root cert I was trying to use was one of those Cross-Signed root certificates which the USG seems to trust because it looks like a root; but, the intermediate did not validate because the USG did not trust the chain...because the USG does not check with any external CAs.
After contacting ComodoCA(issuer of our cert), they were able to provide an alternate Self-Signed root certificate; the USG really trusted this cert as it validated the intermediate which in turn validated our certificate.
Note, both chains validate with OCSP using OpenSSL; but, the USG has an OCSP validation error.I left OCSP turned off.
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 144 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 238 USG FLEX H Series
- 267 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 384 News and Release
- 83 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight