Introduction
Attraqt uses certificates from the Certificate Authority Let's Encrypt for all its secure API endpoints.
LE certificates are valid for 90 days. Attraqt requests new certificates when they are valid for 30 days or fewer, and applies them on API endpoints immediately. This means that during normal operations, certificates are refreshed around every 60 days.
This mechanism is entirely automatic and transparent to Attraqt's infrastructure/operations engineers.
Under normal circumstances, this also does not require any action from Attraqt's customers.
Certificate validation
The certificate validation is commonly executed as follows:
During the SSL handshake, our secured API endpoint offers the site certificate and intermediary certificate. The client verifies the site certificate and intermediary certificate against its root certificates.
The client's root certificates are bundled with the OS, middleware, or application.
Recommendations to customers/integrators
Some applications use the central OS's certificate store, others have their own.
Import the Let's Encrypt root certificates "ISRG Root X1" and "IdenTrust DST Root CA X3" in your OS or middleware certificate store, if they are not already present there. Ensure the import is persisted across your server/middleware restarts.
This will ensure current and future certificate chains are valid.
Specific trust validation
When not trusting the mentioned root certificates, but instead trusting a specific intermediary certificate or even site certificate, the SSL integration can break at any time.
In the case of trusting only a specific site certificate:
- When Attraqt refreshes the site certificate every 60 days under normal circumstance, this requires a new import of the site certificate on the client's side.
- When Attraqt refreshes the site certificate for technical reasons or emergencies, and this could theoretically occur at any time, this requires a new import of the site certificate on the client's side.
In the case of trusting only a specific intermediary certificate:
- When Let's Encrypt changes to a different intermediary certificate (this happened recently, from X4 to R3), this requires importing the new intermediary certificate on the client's side.
- Attraqt currently uses the default chain of validation provided by Let's Encrypt (R3 → X3). If Attraqt certificates were to change to a different chain (such as R3 → X1), either because the default changes or we migrate explicitly, this needs the intermediary certificate for that chain to be imported on the client's side.
It is not always possible for Attraqt to notify its customers of any changes in the certificate chain. We know when certificates will expire, but they may be retired before that date, or at any time due to emergencies.
Real-world example under normal circumstances
When connecting to query.published.live1.fas.eu1.fredhopperservices.com, we can see the site certificate "CN = eu1.fredhopperservices.com" and the intermediary certificate "C = US, O = Let's Encrypt, CN = R3" are returned:
$ openssl s_client -connect query.published.live1.fas.eu1.fredhopperservices.com:443 -showcerts CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = eu1.fredhopperservices.com verify return:1 --- Certificate chain 0 s:CN = eu1.fredhopperservices.com i:C = US, O = Let's Encrypt, CN = R3 (..)
And in the OS, we can see the root certificate "O = Digital Signature Trust Co., CN = DST Root CA X3":
$ openssl x509 -in /etc/ssl/certs/DST_Root_CA_X3.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
Signature Algorithm: sha1WithRSAEncryption
Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
Validity
Not Before: Sep 30 21:12:19 2000 GMT
Not After : Sep 30 14:01:15 2021 GMT
Subject: O = Digital Signature Trust Co., CN = DST Root CA X3
(..)
All three together, this makes for a verified SSL handshake:
$ curl -v -o /dev/null https://query.published.live1.fas.eu1.fredhopperservices.com:443/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 18.202.83.142:443...
* TCP_NODELAY set
* Connected to query.published.live1.fas.eu1.fredhopperservices.com (18.202.83.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4206 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [556 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=eu1.fredhopperservices.com
* start date: Jan 8 08:46:26 2021 GMT
* expire date: Apr 8 08:46:26 2021 GMT
* subjectAltName: host "query.published.live1.fas.eu1.fredhopperservices.com" matched cert's "query.published.live1.fas.eu1.fredhopperservices.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: query.published.live1.fas.eu1.fredhopperservices.com
> User-Agent: curl/7.68.0
> Accept: */*
>
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
Comments
0 comments
Please sign in to leave a comment.