TLS Certificate Transparency is a system where browser vendors require Certificate Authorities to publish information about all of their TLS certificates in cryptographically validated logs, which are generally run by third parties (see also Wikipedia). I've written before about the TLS client's view of this and how it relates to potentially untrustworthy CT log operators, but I haven't written about the Certificate Authority's view of things. The CA's view is also relatively similar to the view a TLS server has.

The normal behavior of a CA is that when it wants to issue a TLS certificate, it will ask various CT logs to give it Signed Certificate Timestamps (SCTs) for the CA's pre-certificate version of the TLS certificate. It will then take those SCTs and stick them in the issued TLS certificate as a certificate extension (also). The minimal thing that CAs can do is verify that the SCTs they receive are properly signed by the CT log and are otherwise well formed to the best of the CA's ability to tell. A CA that wants to be more thorough can save information about new SCTs and watch the relevant CT logs to verify that the log does list the (pre-)certificate before too long, or request a proof of inclusion from the CT log operator.

(I'm not sure if the CAs then also submit the issued TLS certificate to CT logs.)

Since software is fallible, I believe it's smart for CAs to do some degree of spot checking to make sure that CT log operators are successfully adding certificates to their log (SCTs or no SCTs). If your concern is that the CT log updates break in general, you can do this by checking only a small fraction of certificates (either on a percentage basis or just a 'check something every so often' basis). However, I don't know if any CA does this today or if they merely verify the SCTs, given that this is what browsers limit themselves to at the moment.

(A CA verifying that its TLS certificates are in the CT logs doesn't leak information to the CT log operator, unlike the situation with browsers.)

A TLS server with a TLS certificate that has embedded SCTs can verify them in the same way, either minimally by checking that they're signed and otherwise proper or more thoroughly by verifying that the certificate is in the relevant CT logs. Since TLS servers normally deal with a lot fewer TLS certificates than CAs do, this thorough verification may be less of a burden for them than it would be for a CA. If the TLS server has a TLS certificate without embedded SCTs, in theory the TLS server can obtain SCTs, possibly verify them thoroughly, and then provide them through TLS extensions. In practice I believe that all commonly obtained TLS certificates will have embedded SCTs, because that's how you get all of this to work without trying to get tons of people to update tons of web servers.

(See also my entry about what a compromised TLS Certificate Transparency Log can do. For CAs, mostly what a 'bad' CT log can do is provide you with valid looking SCTs but then never add the TLS certificates to the public version of the CT log. The good news is that this will be clearly visible as the CT log's fault, not the CA's fault.)