SSL Communication Standards

BACKGROUND

ERCOT utilizes Secure Socket Layer (SSL) and Digital Certificate standards and protocols to securely transmit data to and from Market Participants. Digital Certificates are required to access, download, submit and query our systems. This document is directed to the API (Application Programming Interface), EWS (External Web Services) download users and ERCOT Notification listeners using server certificates, intermediate certificates or root certificates for testing and production services with ERCOT.

To effectively use web services with ERCOT, users should:

1) Read and understand the External Web Services XSD

2) Download certificates with an understanding of the information captured here

3) Install certificates

4) Test access with Wholesale Client Services using MOTE

5) Escalate any questions or issues to the ERCOT help desk.

VENDOR CHANGES

ERCOT has contracted with the SSL Certification Authority GlobalSign for to secure market facing ERCOT websites. ERCOT has provided the updated Root and Intermediate Certificates to allow the ERCOT websites to function with Market Participant Automated Programmatic Interfaces (APIs).

To meet the Secure Hash Algorithm 256 (SHA256) server to root algorithm requirement, ERCOT is utilizing the SHA256 public Root Certification Authorities.

CERTIFICATES

The following certificates are the minimum required for SHA256 key communication to the ERCOT Web Service API for submissions, queries and MarkeTrak API(MISAPI.ERCOT.COM), the Market Information System GUI (MIS.ERCOT.COM), as well as the ERCOT Notifications system. Market Participants should either add these certificates to the existing keystore or create a blank keystore with just these certificates installed after the configuration. The entire SSL Chain is required for both the Production and MOTE environments. The Client Root Certificate is required for the respective environment.

Required SSL Chain Certificates:

- Production and MOTE

Current SSL Certificate Chain

- SymantecSHA256CAIntermediate.cer (Symantec SHA256 Intermediate Certificate)

  • SymantecSHA256CA.cer (Symantec SHA256 Root certificate)

Future SSL Certificate Chain:

  • GlobalSign RSA Organization Validation CA - 2018.cer (GlobalSign RSA Organization Validation CA - 2018 Intermediate SSL Certificate)

  • GlobalSign Root R3.cer (GlobalSign Root R3 SSL Certificate)

Required Client Root Certificates:

- Production

- ERCOT_CA.cer (ERCOT’s 2048-bit Production Client Root Certificate)

- MOTE

- ERCOT_TEST_CA.cer (ERCOT’s 2048-bit TEST Client Root Certificate)

ERCOT PUBLIC KEYS

ERCOT previously provided API public key available for use with ERCOT initiated API communication (e.g. Notifications). As part of the SHA256 upgrade, Market Participants are encouraged to trust the new SHA256 Intermediate and Root certificates, instead of the Notification SSL public key. The SHA256 Intermediate and Root certificates will need to be installed in both sending and receiving API’s.

The diagram below explains a typical keystore location and the minimum required certificates after the SHA256 SSL certificate upgrade..


Appendix A – Secure Socket Layer (SSL)

SSL is a standard mechanism for Web services that is available on virtually all application servers. This widely used, mature technology, which secures the communication channel between client and server, will satisfy all of ERCOT’s use cases for secure Web Service communications. Since it works at the transport layer, SSL covers all information passed in the channel as part of a message exchange between a client and a server, including attachments. Authentication is an important aspect of establishing an HTTPS connection. Many platforms support the following authentication mechanisms for Web Services using HTTPS:

  • The server authenticates itself to clients with SSL and makes its certificate available.

  • The client uses basic authentication over an SSL channel.

  • Mutual authentication with SSL, using the server certificate as well as the client certificate, so that both parties can authenticate to each other.

Appendix B – API SSL Communication

With Web Services, the interaction use case is usually machine to machine; that is, it is an interaction between two application components with no human involvement. Machine-to-machine interactions have a different trust model from typical website interactions. In a machine-to-machine interaction, trust must be established proactively, since there can be no real-time interaction with a user about whether to trust a certificate. Ordinarily, when a user interacts with a website via a browser and the browser does not have the certificate for the site, the user is prompted about whether to trust the certificate. The user can accept or reject the certificate at that moment. With Web Services, the individuals involved in the deployment of the Web Service interaction must distribute and exchange the server certificate, and the client certificate (for mutual authentication), prior to the interaction occurrence.

For Windows based API applications, the root certificate attached to this notice will need to be installed into the trusted root certificate store at the server level. This can be done through the Microsoft Management Console. An application restart is suggested to recognize the new certificate.

For UNIX based systems, the root certificate will need to be converted based on your specific application requirements and installed into the local trusted root certificate store.

Appendix C- Example Installation Instructions

For Windows based API applications, the root certificate attached to this notice will need to be installed into the trusted root certificate store at the server level. This can be done through the Microsoft Management Console. An application restart is suggested to recognize the new certificate.

For UNIX based systems, the root certificate will need to be converted based on your specific application requirements and installed into the local trusted root certificate store.