Opened 13 years ago
Closed 13 years ago
#31965 closed defect (invalid)
mercurial @1.9.3_0 SNI not supported?
Reported by: | m@… | Owned by: | deric@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.3 |
Keywords: | SNI | Cc: | |
Port: | mercurial |
Description
It seems that port mercurial @1.9.3_0 does not support SNI (Server Name Indication) properly.
When hg
connects to a server that hosts multiple virtual hosts with individual SSL certificates, it takes the first certificate always (thus, the certificate from the host that serves https://IP/).
In my ~\.hgrc
I defined fingerprint F_B for server S_B. However, hg
complains about an invalid certificate with fingerprint F_A. This fingerprint F_A belongs to server S_A, and not to S_B; thus, mercurial chooses the wrong certificate. As soon as I change the fingerprint of S_B to F_A (thus, an actually wrong one) in ~\.hgrc
, it will work.
Change History (4)
comment:1 Changed 13 years ago by m@…
comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | deric@… removed |
---|---|
Owner: | changed from macports-tickets@… to deric@… |
Have you already reported this issue to the developers of mercurial? Or do you have reason to believe it's a MacPorts-specific problem?
comment:3 Changed 13 years ago by m@…
Good point. After I had investigated this issue further, I was able to narrow it down to the fact that Mercurial does not support Python 3.2. While Python 3.2 supports SNI, 2.x does not and will never do. See http://mercurial.selenic.com/bts/issue3090 for more details.
I suggest you close this issue.
comment:4 Changed 13 years ago by deric@…
Resolution: | → invalid |
---|---|
Status: | new → closed |
Thanks for the rundown, closing.
This issue could be caused to port openssl and / or port python27. However, at the moment I have no way of replicating this issue without mercurial.