43

Or are certs both host- and port-specific (excepting wildcard certs)?

I would assume they aren't, because they're supposed to verify a domain, but at the same time I've never seen anyone run HTTPS on any port other than 443, and I've only seen X.509 certs used in conjunction with HTTPS, so despite the fact that the answer is probably "no", I wanted to check.

Parthian Shot
  • 861
  • 2
  • 10
  • 18

2 Answers2

45

Theoretically you can put anything you want in a certificate; for instance, this certificate actually contains a video file as "Subject Alt Name" (surprisingly, Windows has no trouble decoding a 1.2 MB certificate -- but it does not show the video, alas). However, in practice, certificates "for SSL" just contain the intended server name, as specified in RFC 2818. The client (Web browser) will verify that the name from the URL indeed appears where it should in the certificate. There is no standard for storing a port number in the certificate, and no client will verify the presence of that port number anyway, so, in short words: certificates are not port-specific. The notion of "identity" that certificates manipulate and embody does not include the notion of "port".

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    There's an implied link to the allowed protocol(s), by way of (extended) key usage, e.g. "TLS Server" or "email Protection", e.g. a cert [only for S/MIME email use](http://security.stackexchange.com/questions/30066/which-extensions-to-use-for-a-s-mime-certificate) should not be supported for TLS at all. One of the permitted subjectAltName types is uniformResourceIdentifier, which *could* contain a port number. I strongly suspect support for that is close to non-existent ;-) – mr.spuratic Jul 11 '14 at 11:00
  • 4
    The Extended Key Usage extension is kinda supported (at least in the Microsoft world) but clients will probably ignore it if it is not marked "critical". Anyway, HTTPS is not specific to port 443 (this is just the port by default, but you can do HTTPS with other ports, that's standard and supported). As for alternate names of type URI, HTTPS client will completely ignore them: RFC 2818 is quite clear, in that it mandates usage of names of type `dNSName` only. – Thomas Pornin Jul 11 '14 at 11:27
  • Great, thanks. Some quick research indicates its use seems to be limited mostly to SIP/SDP/MSRP, EAP-TLS and XMPP protocols, i.e. where identity is more fine-grained than a hostname or IP address. – mr.spuratic Jul 11 '14 at 12:41
  • 1
    Nitpick: 2818 allows dNSName and/or iPAddress for HTTPS, although 6125 (in 2011) supports only dNSName for new applications. But it's usually a bad idea to use addresses for certs and URLs on the public net (and from a public CA like a CABforum member) because there are too many situations where an address must be changed; OTOH it _may_ be reasonable on an intranet. – dave_thompson_085 Mar 05 '18 at 21:50
-5

It seems to matter if you need the fingerprint of a cert and you get different hashes where used on different ports and you need to use SSL on both. I'm not quite sure why this is, but with 90 day certificate lifetimes I keep having to patch my fetchmail configuration until I figure out how to get it to verify the full chain of trust. 

rich@mars:~$ echo | openssl s_client -connect subdomain.example.net:993 -showcerts | openssl x509 -fingerprint -noout -md5
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
MD5 Fingerprint=D6:2F:CD:EF:D3:26:5A:B5:15:24:E5:55:1F:99:B8:B9
rich@mars:~$ echo | openssl s_client -connect subdomain.example.net:443 -showcerts | openssl x509 -fingerprint -noout -md5
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
MD5 Fingerprint=7C:3B:53:41:55:43:F7:B6:F5:BE:C9:8F:E3:CD:BD:A1
schroeder
  • 123,438
  • 55
  • 284
  • 319
Richard Copsewood
  • 1