5

Latest Chrome/IE9/Firefox all work fine. IE8 complains that the page cannot be shown and it looks like that the connection is aborted. Here goes the quick test code.

package main

import (
    "time"
    "fmt"
    "net/http"
)

type Handler struct {
}

func (this *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, %q", r.URL.Path)
}

func main() {
    handler := &Handler{}
    ss := &http.Server{
        Addr: ":443",
        Handler: handler,
        ReadTimeout: 10 * time.Second,
        WriteTimeout: 10 * time.Second,
        MaxHeaderBytes: 1 << 20,
    }
    ss.ListenAndServeTLS("cert.pem", "key.pem")
}

Note that "cert.pem" and "key.pem" are generated by "crypto/tls/generate_cert.go". I tried a real certificate, and it did not work either.

Denys Séguret
  • 372,613
  • 87
  • 782
  • 758
albert
  • 364
  • 3
  • 8

2 Answers2

1

TLS is a standard, so there's no such thing as "TLS of IE8" or something like this.

I suppose the problem is that IE8 does not trust your (supposedly self-signed) certificate. So I think you could find an answer in this thread here on SO.

You can also have a properly signed certificate but the certificate storage on the computer running this IE8 instance does not have the certificate of your CA (or the whole trust chain of certificates if your certificate has been signed by a subordinate CA) imported and hence trusted. In that case you should do exactly that — get the certificate of your CA (or the whole chain of CAs, if any) and import it on the client machine.

Community
  • 1
  • 1
kostix
  • 51,517
  • 14
  • 93
  • 176
  • iPad might be trickier to handle as one usually has hard time getting things uploaded onto it. I once successfully imported my CA's certificate to a user's iPad by uploading the `#PKCS12` file generated out of that certificate to a trusted local webserver and then navigating to its URL in Safari on iPad -- upon downloading, it automatically offers to import that certificate. – kostix Sep 28 '12 at 16:21
  • 3
    Thanks for replying. I actually meant **the current state of TLS implementation in the golang standard library** , but sorry for the confusing expression anyway. I learnt from a golang forum that the problem is due to SSLv2 handshake response. Here is the related issue thread, http://code.google.com/p/go/issues/detail?id=3930 . – albert Sep 29 '12 at 02:08
0

moved from question as OP didn't made a proper answer

This problem can be resolved by this patch, "0001-Allow-SSLv2-compatible-client-hello-so-SSLv2-compati.patch", in issue http://code.google.com/p/go/issues/detail?id=3930.

This revision, http://code.google.com/p/go/source/detail?r=8048fe8f6f4b, however, does not solve the problem.

Denys Séguret
  • 372,613
  • 87
  • 782
  • 758