Timeline for Error in SSL handshake with a web service - chain violates basic constraints limit
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 7:59 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| Jun 16, 2020 at 9:49 | history | edited | CommunityBot |
Commonmark migration
|
|
| Aug 5, 2018 at 9:42 | comment | added | StackzOfZtuff | @abhishek: 1. see above re. intermediates. 2. Also: what does SSL-Labs say about the chain? 3. And the guy on the server side. What’s his explanation for having two roots in that chain? | |
| Aug 5, 2018 at 9:35 | comment | added | StackzOfZtuff | Now the non trusted (not the same thing as “distrusted” mind you) intermediates that you might need as additional pieces of the puzzle (if and only if you need to construct the chain yourself and not if you want to verify a given one) you’d keep in a seperate set. So you’d have these seperate sets: explicitly-trusted (“trust anchors”), explicitly-distrusted, untrusted-intermediates. And what you’ve done is that you have placed intermediates that should have gone in the untrusted set in the trusted set instead. — When you construct a chain to a trusted cert you’re DONE. “Link”crt? PleaseRecheck | |
| Aug 5, 2018 at 9:24 | comment | added | StackzOfZtuff | Well you’ve abandoned a usual aspect of the PKI concept here. You usually declare some certificates as “trust anchors” and set explicit trust for them. Then later in actual use you will encounter a subordinate certificate of some kind that you will need to make a trust decision on. Because you don’t know if you should trust it or not yet. And then you try to build a chain (or verify a given chain) that starts in the new cert and should end in one od your explicitly trusted trust anchors. And never touch anything explicitly distrusted along the way. You’re DONE when you reach a trust anchor. | |
| Aug 4, 2018 at 23:01 | comment | added | Ccy | Could you please explain why is trusting an intermediate cert incorrect? The tool we use validates the chain being sent from the server and also validates if the intermediate certs are trusted (present in the local trust store). 2. You are correct about i2. It does appear to be a valid root cert (as mentioned in my original post), but since the server is sending an i3 after i2, hence my tool is not recognizing it as a root cert (this is what I meant by i2 not being treated as a root). As you said, either the chain is invalid or as Mike explained, maybe my tool does not understand link certs? | |
| Jul 28, 2018 at 17:34 | history | edited | StackzOfZtuff | CC BY-SA 4.0 |
added 129 characters in body
|
| Jul 28, 2018 at 17:11 | history | edited | StackzOfZtuff | CC BY-SA 4.0 |
added 675 characters in body
|
| Jul 28, 2018 at 17:01 | history | undeleted | StackzOfZtuff | ||
| Jul 28, 2018 at 16:58 | history | deleted | StackzOfZtuff | via Vote | |
| Jul 28, 2018 at 16:51 | history | answered | StackzOfZtuff | CC BY-SA 4.0 |