Our automatic signing system runs in an isolated network having tightly restricted connectivity, just to timestamping and some other necessary services. Timestamping occasionally fails when the IP addresses change. Configuring the IP address range for this in our firewall could increase the robustness of our internal code signing service.
Recommend your firewall admins permit outbound access to Apple's entire assigned IP space of 17.0.0.0/8.
One more thing about timestamp.
We finally found a ways to codesign with --timestamp=http://timestamp.apple.com/ts01 and the process result was OK.
So far so nice. But notary service complained, that the timestamp is insecure.
Looks to me like the timestamp server response is embedded as "raw" data. Due to App Transport Security a TLS connection will be used regardless the URL uses plain http. With the raw response comes the server certificate - which allws not only to decrypt the timstamp payload but also to verify the identity of the server the timestamp created.
Basically this is smart.
Caveate: when your proxy/firewall/gateway uses man-in-the-middle techniques to inspect the response from the server for any kind of malware - then it has to re-encrypt the response before it gets forwarded to the requesting client. The timestamp still looks fine and codesign -dvvv --strict shows the timestamp as expected - but the Notary Service considers the timestamp as insecure as the certificate data embedded in the timestamp is not trusted.
I just have experience this. App signed on our buildsystem has insecure timestamp. Re-Signing it with the same commandline while using a network without proxy/firewall/gateway works - teh timestamp is considered as secure.
I just thought this is worth to mention if other run into a similar situation. Let's see if IT can solve the issue...
