Summary

  • Netscape’s December 1994 launch release already presented SSL as part of its Commerce Server, while a later engineering history says Navigator 1.0’s security code supported SSL 2.0.
  • SSL 3.0 became an expired IETF Internet-Draft in November 1996; the IETF’s stable historical reference did not arrive until RFC 6101 in 2011.

The first evidence is not a standards document. In December 1994, Netscape announced Navigator 1.0 and its Netsite server line. The contemporary release described the Commerce Server as incorporating Secure Sockets Layer technology based on RSA Data Security, and said the client and server could support secure Internet commerce. It is a company’s launch claim, not an independent count of installations. But it places SSL inside a product offered to the public before the surviving standards record became stable.

A later history of Netscape’s security code supplies a version detail the launch notice does not: Navigator 1.0 supported SSL 2.0, while Navigator 2.0 added SSL 3.0. The same account says the security code was adapted for Netscape’s 2.0 servers. This is first-party engineering recollection, not a shipment census; it should be read alongside, not substituted for, the dated product announcement.

The 1995 record shows the protocol moving into public technical description. An archived copy identifies “The SSL Protocol” by Kipp Hickman and Taher Elgamal as a June 1995 Internet-Draft. A February draft preserved in Mozilla’s archive explains SSL as an application-independent layer: a handshake negotiates cryptographic parameters and authenticates a server before application data flows. These documents describe implementable behavior. Their status as drafts did not make them an approved Internet Standard or guarantee that every implementation interoperated.

SSL 3.0 makes the distinction unusually visible. The IETF Datatracker lists draft-ietf-tls-ssl-version3-00 as an expired Internet-Draft, last updated on 21 November 1996, with no intended RFC status. The text itself is dated 18 November. In 2011, RFC 6101 published that version as a historical record. Its foreword says SSL 3.0 had been widely implemented and underlay TLS, yet had never been formally published by the IETF except through expired drafts. The RFC’s purpose was to create a stable reference, not to retroactively turn SSL 3.0 into a standards-track specification.

That timeline does not mean SSL had no specifications, or that standards bodies were absent. It shows that different records answered different questions. Product releases establish what a company offered; code histories report what a family of clients supported; drafts make a protocol available for scrutiny and change; a published RFC provides a durable, citable document with a stated status. None alone proves universal deployment or equivalent behavior.

The practical lesson is to avoid treating adoption as a single event. A working implementation can attract use before a stable specification exists. A draft can improve interoperability without certifying it. And a later historical RFC can make an old protocol legible without endorsing its security or current use. For SSL, the product, the working text and the lasting citation arrived on different clocks.