-
Star
(398)
You must be signed in to star a gist -
Fork
(71)
You must be signed in to fork a gist
-
-
Save Manouchehri/fd754e402d98430243455713efada710 to your computer and use it in GitHub Desktop.
| https://rfc3161.ai.moda | |
| https://rfc3161.ai.moda/adobe | |
| https://rfc3161.ai.moda/microsoft | |
| https://rfc3161.ai.moda/apple | |
| https://rfc3161.ai.moda/any | |
| http://rfc3161.ai.moda | |
| http://timestamp.digicert.com | |
| http://timestamp.globalsign.com/tsa/r6advanced1 | |
| http://rfc3161timestamp.globalsign.com/advanced | |
| http://timestamp.sectigo.com | |
| http://timestamp.apple.com/ts01 | |
| http://tsa.mesign.com | |
| http://time.certum.pl | |
| https://freetsa.org | |
| http://tsa.startssl.com/rfc3161 | |
| http://dse200.ncipher.com/TSS/HttpTspServer | |
| http://zeitstempel.dfn.de | |
| https://ca.signfiles.com/tsa/get.aspx | |
| http://services.globaltrustfinder.com/adss/tsa | |
| https://tsp.iaik.tugraz.at/tsp/TspRequest | |
| http://timestamp.entrust.net/TSS/RFC3161sha2TS | |
| http://timestamp.acs.microsoft.com |
@Manouchehri I am afraid there is a confusion.
The "proxy" https://rfc3161.ai.moda/azure -> http://timestamp.acs.microsoft.com/ works fine.
The thing is that we need to regularly download CA root certificates for our timestamping service to work.
As http://timestamp.acs.microsoft.com/ is not listed in https://rfc3161.ai.moda/servers.json the script you provided for CA root certificate download does not get the certificate for http://timestamp.acs.microsoft.com/
@vasekkral Can you please provide any code to show that the certificate on https://rfc3161.ai.moda/azure vs. http://timestamp.acs.microsoft.com is different? (Spoiler hint: it's not different.)
Microsoft Azure's timestamping server itself doesn't use the exact same full certificate chain on each result. You can check this yourself.
openssl rand 512 | openssl ts -query -data - -cert -sha512 | curl -s --data-binary @- http://timestamp.acs.microsoft.com | openssl ts -reply -in /dev/stdin -token_out -out /dev/stdout | openssl pkcs7 -inform DER -in /dev/stdin -print_certs -text | grep "nShield TSS
Outputs from multiple runs:
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft America Operations, OU=nShield TSS ESN:7A00-05E0-D947, CN=Microsoft Public RSA Time Stamping Authority
...
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft America Operations, OU=nShield TSS ESN:7D00-05E0-D947, CN=Microsoft Public RSA Time Stamping Authority
See how the OU field changes? Microsoft's servers have more than one Thales nShield HSMs. So your idea would never have worked, except sometimes at random by pure chance.
The thing is that we need to regularly download CA root certificates for our timestamping service to work.
You are making fundamentally error(s) in your approach. If you request the certificate to be included in the TSR, there is no need to download any CA root certificates on a regular basis. You only should be downloading and trusting ONE root CA from Microsoft.
If you do this, you should not need download a new CA cert from Microsoft until 2045.
The only regular downloads you should do, are checking to make sure the certificate hasn't been revoked.
@Manouchehri thanks for comprehensive explanation. I get it now and everything works just fine.
@vasekkral Can you share how you're checking that? On my end, I can definitely see that
https://rfc3161.ai.moda/azureis proxied tohttp://timestamp.acs.microsoft.com. You can always verify this by looking at theviaheader. (e.g.via: HTTP/1.0 timestamp.acs.microsoft.com,via: HTTP/1.0 timestamp.digicert.com,via: HTTP/1.0 timestamp.sectigo.com, etc.)