ERCOT 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) and EWS (External Web Services) download users 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 previously provided the updated Intermediate Certificates to allow the ERCOT websites
to function with Market Participant Automated Programmatic Interfaces (APIs).
To meet the 2048-bit server to root RSA key requirement, ERCOT has upgraded all SSL
Certificates used to secure the ERCOT websites to 2048-bit RSA keys utilizing the 2048-bit
RSA public Root Certification Authorities.
As of September 30, 2011, all API traffic is required to communicate using the new 2048-bit
RSA SSL Root configuration (Refer to Appendix B below). The Market Operations Testing
Environment (MOTE) has been configured to utilize this configuration to facilitate Market
Participant testing.
CERTIFICATES
The following certificates are the minimum required for 2048-bit RSA key communication to the
ERCOT Web Service API for submissions and queries (MISAPI.ERCOT.COM) as well as
report downloads (MIS.ERCOT.COM). 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
- VeriSign_Class 3_International_Server_CA_G3.cer (VeriSign 2048-bit
Intermediate Certificate)
- VeriSign_Class_3_Public_Primary_Certification_Authority_G5.cer (VeriSign
2048-bit Root 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
ERCOTs public key is required to receive alerts and notifications and is used to ensure secure
messages are coming from ERCOT. ERCOT has made the API public key available for use with
ERCOT initiated API communication (e.g. Notifications). The API public key is not required
for Market Participant initiated API communication to ERCOT (e.g. GetReports, Submissions,
or ReportDownloads). Only if one keystore is used between both the sending and listening API
applications, then the public key will need to be installed as well.
The diagram below explains a typical keystore location and the minimum required certificates.
Notification Sender
Application Keystore
- ERCOT's Production MISAPI
Public Key
- Customer SSL Root Certificate
Query/Submission
Application Keystore
ERCOT APE
- VeriSign 2048-bit Intermediate
Certificate
- VeriSign 2048-bit Root Certificate
- ERCOT's Production 2048-bit
Client Root Certificate
Notification
Communicaiton
Report Download
Application Keystore
ERCOT Proxy
Submissions, Queries,
and Report Download
Communication
- VeriSign 2048-bit Intermediate
Certificate
- VeriSign 2048-bit Root Certificate
- ERCOT's Production 2048-bit
Client Root Certificate
Notification Listener
Application Keystore
SSL Keystore
- MP’s 2048-bit SSL Certificate
- MP’s 2048-bit SSL Intermediate
Certificate
- MP’s 2048-bit SSL Root Certificate
- VeriSign 2048-bit Intermediate
Certificate
- VeriSign 2048-bit Root Certificate
- ERCOT's Production 2048-bit
Client Root Certificate
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-tomachine 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.