Certificate Transparency Logs: Roadmaps to Riches or Ruin?

it's good to be back at b-sides it's been a few years so just a round of applause for the volunteers today and everybody else coming together to make this a reality again my name is Nolan reisbeck like she said uh I'm a platform engineer at MasterCard I've been there for a little while and today I'm going to be talking a little bit about uh certificate certificate transparency logs and the dangers that lie there in um so I left Oakland um three or four years ago I moved back home to bend um I'd probably rather be skiing or sailing but um I was thrilled to have the opportunity to come back and present it besides this year so

um I've got two dogs and my girlfriend is at home she couldn't make it but I also do want to thank her for putting up with me in the last couple weeks of trying to pull this all together so for patience is appreciated

so a little overview of the talk here I do want to talk uh just kind of about different types of SSL certificates I know this is a deep dive but I want to make sure that we're kind of all on the same page and talking about the same things we're going to talk a little bit about the history of certificate transparency logs um why we need them and how we got here um how we well how we uh arrived at the need for them there's a little bit of a history lesson in there uh we're going to talk a little bit about the process of how your Certificate request um becomes published into a certificate

certificate transparency log um as well as what that whole process and how all the parts and pieces fit together when you go off and request a certificate until you get that certificate back we're going to talk a little bit about commercial and Homebrew Solutions for monitoring um the various logs that are out there we'll do a little quick detour into kind of a lot a live stream of a certificate transparency log and then I've got a little bit of a demo to go through and then we're going to wrap things up by talking a little bit about um like tying it all together certificate transparency logs for um The Blue Team Defenders as well as

people that may consider themselves more on the red team side of things or purple team um how you can use an abuse certificate transparency logs and what all is out there to find and then we'll have a little bit of QA time q a time after that so so a brief primer um on certificate transparency logs we've got three different types of SSL certificates out there the vast majority of SSL certificates when they're issued are going to be domain verified and what that means is that you just have to present some modicum of control over the uh the record for the domain that you're requesting whether that's a verification or validation through some well-known file

um add a path like an HTTP request you can also verify demonstrate ownership of the domain that you're requesting for via a text record um so that's another DNS record type um generally speaking you'll get some sort of random string to plug into the value of that text record and then the certificate issuer or the certificate Authority issuing that certificate will then go and wait some time look up the value of the text record if it matches the value that they provided you and told you to put it in there they will turn around and do what they need to do on their side and then hand you back a certificate so kind of generally

speaking that's the that's the flow for domain verification through let's encrypt or the Acme process but there are other Cas out there that will do like email verification or things like that so big takeaway there DV certificates are probably what you're getting unless you're going out of your way to do a lot more paperwork which I don't enjoy and I'm sure you probably don't too but we will cover those here briefly tight number two we have an OV certificate or organization validated and what that means is that if you go out and request a certificate for um like a business um widgets Co um you would probably want a little bit more rigor around the process of that so

the ca will require some paperwork um they will basically well I'm sorry I got ahead of myself there um the request or you when you go off and request an OV certificate you'll provide a little bit more information to them they'll put a couple of oids on there which are just object identifiers in the certificate field I've thrown a couple up there just for reference they're not important you don't need to memorize those so basically you basically just have to provide an expanded certificate subject on there that just says you know this is for example Company Incorporated in some Town California they'll go off and basically use one of like four or five different business database

verifications to say yeah some some company example company is incorporated um in in that state and then they'll turn around and issue your certificate so third and final type um we have uh an extended validation um an EV certificate so generally speaking you'll kind of see these types of certificates used for um Financial processing you know credit card transactions things like that you would generally hope that your bank is probably using these there is significantly more rigor around these certificates and the process there and it is up to the ca or the issuing authority on that the to do that validation so the certificate Authority and browser Forum will set the validation requirements um there's like four different 200 Page

docs out there if you want to go through and read those we're not going to talk about too much of that right now but the primary purpose of an extended validation certificate would be to identify the actual legal entity that controls a website or that domain I should say so um you're generally not going to see those through the fishing or stuffing campaigns the look-alikes and you know those those will just be generic um certificates but one kind of big thing to note there is that the the the big browsers out there don't really [Music] um make it very evident they used to um the EV certificates will give you a little green padlock um there used to be

a little bit more but there's not uh there's not too much more to the user if you're going to your bank and logging in and you see the little padlock icon up there next to the bar you're probably not going to go inspect that certificate to make sure that there's an oid on it um as an end user you don't really care about that kind of thing um so the cab validation requirements like I said the primary purpose is to identify the legal entity that controls the domain um and secondarily to make it more difficult for fraud and other types of identity attacks to happen however an EV certificate is not intended to represent or warrant that the legal

entity named in the certificate um is actually currently still doing business or that it is compliant with local laws in their jurisdictions um or furthermore I put this as three but it's also kind of important to talk about um by getting an Eevee certificate the the cab and the ca is not actually attesting to your trustworthiness or honesty um as a business entity um they just want their money and they're going to issue you their certificate they've done a little bit more checking into kind of who you are um and it's also not safe to assume um that you can do business with this company presenting a certificate so that being said um they just wanted to

put that out there it's in one of their documents up at the very top um but they will turn around and issue their certificate they've just done their homework and can a test that the legal entity requesting that certificate actually represents that domain so uh organization types we did talk about this just a little bit um there's uh four different organization types um that you know you when you go and request an easy EV certificate they will bucket your request into a particular type of entity and that will be published on the certificate um a private organization is generally going to be the vast majority of companies that would request a certificate like that your LLCs are limited in the UK

gmbh in Germany and limited liability Partnerships um there's also government entities um I think that's kind of obvious so um like the NIH or the IRS a government entity and that entities legal existence was established by the political um powers in the jurisdiction which they operate and they have said yes you are the Revenue Service for the US you may have a dot gov tldn domain business entities um this is a little murky um it's kind of General Partnerships unincorporated associations joint ventures and Sole proprietorships and then there's also non-commercial entities so non-profits academic institutions higher education things like that so yeah we get into a little bit of the need so um in 2011 there was a

well there still is a CA um Komodo had a little bit of an Oopsy Daisy um and uh Moxie Marlin's bike gave a really good talk on this a while back um it was probably five six eight years ago um but on March 15th um there was uh it was discovered that the registration Authority instant SSL um which was an issuer for Komodo um had a little bit of security incident and using this registration Authority a other time unknown person um went and issued nine certificates across seven domains um four some pretty big companies Google Yahoo Skype Mozilla Microsoft and then one final one down here Global trustee with the cereal uh it was never really ascertained what

that certificate was issued for it was not issued for a valid domain and kind of the running Theory and at least the one that still kind of accepted this time is that that was a certificate certificate that may or may not have been used likely may have been used for login to um maybe some some more of the back ends that exist in the ca world the Yahoo one up here in bold um this serial number was the only certificate that was issued by this attacker that was ever seen in the wild um and so what that means is that this person went and issued all of these certificates um for mail.google.com you know you go

log into your Gmail if they had the opportunity to do that we're let's say for example running the Wi-Fi in your hotel they could use that certificate and that would allow them to redirect the traffic from actual Gmail to something presenting itself as Gmail probably looks the same probably acts the same until you click login and uh the whole point of that was Prudential harvesting but of those uh let's say eight certificates the login.yahoo one from this breach that was issued um by Komodo was the only one that was ever actually seen to be used the rest of them nobody at the time really had any idea what this person was up to what their plans were

or what might happen but the uh sorry after the fact there was somebody that did publicly claim on the internet they posted a um a paste bin um document dump basically saying here's who I am I take responsibility for this and generally kind of at the time people were just kind of you know skeptical about that there was a few security researchers out there that were like uh I don't know it seems like you might just be trying to take credit for this for the glamor um but they did end up supplying a little bit of evidence that moved those claims from the realm of skepticism into oh boy this might be a problem after that so that was back on March

15th of 2011. so a few months later in August during the summer uh there was a gentleman in [Music] um Iran that posted this very innocuous innocuous looking um kind of plea for help he seemed very baffled at the time by it um but he found um the now defunct this was this screenshot was a nightmare to track down I I could not find it all the links are dead um Google's replaced all their product forums but I did finally find it um but he said I tried it basically in in essence I tried to log into Gmail um and I got a certificate warning in Chrome um you know just that little red box

that says this certificate is invalid he said I took a screenshot and I saved that certificate to the file to a file here's that certificate file and a screenshot um he uploaded it to MediaFire um and then he said here's the text of this decoded fake certificate posted it on pastebin for other people to look at and he said and then I logged into my VPN um and I went to Gmail again and it worked just fine um what's going on there was like a thing at Komodo that happened that I had heard about um but that was really kind of it and uh what I found most amusing about this um post was one that it was just kind of

in a dark corner of the web on the Google product forums under the off topic um the coffee shop if you will so um just hey I noticed something weird going on with Google today um which I don't know if anybody any anyone has ever dealt with um end user support but you get a lot of um requests and things like that hey this is kind of weird and nine times out of ten They Don't Really pan out but um unfortunately for all of us this gentleman was uh actually spot on with that um so August 28th um let's just kind of keep that date in mind so that was um seven months after the initial Komodo

breach is a little a little hard to see here so I'm going to squint at my screen um so basically the the public timeline um of This was um there was another breach this time it was through another CA called Digi notar um and so August 28th third line down there uh was one of our little friend posted his um message to the support forum is this a man in the middle attack to Google's SSL July 10th was the date of the uh actual certificate issuance um Somebody went and breached did you know tar we don't know when they we do now but at the time we didn't but somebody went out and looked and said okay that

certificate that he posted on there you can go look at it you can see the not valid form before date you can see it was issued um July 10th there was a few more certificates issued for Google sub domains but the last one was issued on July 20th so a 10-day time span um and then basically a month after those certificates stopped being issued is when the world generally found out about it immediately the mines over at Google sprung into action and on July 29th they basically posted a statement saying that they were aware that a certificate had been issued by this ca for a domain that they controlled and they assured everybody that they did not request it

um there were uh there was a statement that was made um by Mozilla the same day and uh Microsoft as well so the folks over at the cab Forum uh they're generally pretty responsive to each other and when problems like this arise it's generally a pretty cohesive thing and so the consensus was is that that certificate would be distrusted um in the browsers Chrome Mozilla and um Internet Explorer Edge Etc the day after that Vasco the parent company of diginotar um issued a public statement basically kind of downplaying it um now if you're following along that was uh 51 days after um the fraudulent certificates had been issued which isn't really a great look um they kind of slow rolled that and

they really didn't say too much about it they said that they were kind of looking into it and basically said that it really wasn't um too much of a cause for concern which I think we can all agree um it should have been the um Roundup of all of the certificates that were issued by diginotar in uh in this whole Fiasco were published to a a mailing list on f-secure I think that there was uh let's see here there was quite a few of them and um on September 1st um chromium and Google revoked 257 certificates issued by Digi notar and then they revoke the genotars root certificate um now if you're a CA and your entire

business purpose is to provide trust and you're out there issuing certificates for entities and domains that the actual controller of that domain didn't ask for and you don't know where they went that doesn't really instill confidence in the public and uh isn't very trustworthy so as a CA basically the only thing that you have is um your word and your processes and procedures for why that's not going to happen and if it does that trust kind of evaporates and there is not really much reason for you as a CA to exist anymore so September 2nd Mozilla issued a follow-up statement um basically confirming the same exact thing saying that they would also follow suit with the chromium project they

would be blacklisting all of the or I'm sorry they would be revoking all the certificates in um in Mozilla and uh basically disallowing those to be trusted so if somebody was using that certificate and a end user went navigated to a website and that website presented that certificate big old Banner um September 3rd uh yeah September 3rd the uh the Dutch government also revoked trust in the did you notar route now this is um also kind of important because the Dutch government used Digi notar as their primary ca for a lot of things like taxes and um Healthcare and things like that so chromium's out mozilla's out the Dutch Government is out um and things are not really looking so

good for did you notar um September 5th the interim report on what happened there uh was published the same day that that report was published um did you know tar decided it was finally time to pick up the phone and Report the breach to the Dutch police shortly after that um the next week they officially filed for bankruptcy um and the day after that a Dutch Court basically accepted their bankruptcy filing they would cease to operate as a legal entity in the Netherlands and issue uh no more certificates wanted or unwanted so that's the public timeline now we get to go into what really happened did you know Tara was compromised way back on June 6th

um which is far before um August when our our friends posted that to the Google forums July 10th um there was a wild card certificate issued for google.com um and so that's not just mail.google.com that could be anything else under that um single subdomain Google you could use that certificate to do all sorts of awful and terrible things and that certificate was not revoked until about a month and a half later on August 29th so just a few days after the problem was surfaced in that product Forum um July 10th somebody over at Digi notar noticed an automated test had failed to work raise your hand if you work in an organization that uses Jenkins or

something else like that to run CI testing and tests fail a lot right and you go yeah that broke it's probably not a very big deal uh we'll look at it it's Friday afternoon two o'clock I'll look at it on Monday um I'm not saying that that's what happened but somebody over there noticed that on July 10th one of their integration tests failed and that integration test basically what that integration test did um was that it went out and looked at all of the certificates that that CA issues and I looked at all of the requests please sign me a certificate for google.com I've issued you a certificate for google.com however things didn't line up

um and that was kind of the big problem they realized that there was a whole bunch of certificates out there that they had no requests for um and so they went and fixed um that test um took about a week and uh the administrative records um like I said the the administrative the the number of requests and the number of issued certificates in the end just didn't match up that's all that test was meant to show uh July 20th they found a script somewhere presumably on uh one of those agents or you know I'm just positing here um one of the systems that was running the tests they found a little bit of um leftover cruft that wasn't cleaned up so

the attacker didn't really um clean up after themselves and they kind of shot themselves in the foot there they also found out that there was even more certificates that hadn't been requested that were issued um on July 27th they engaged in external security firm um the official report that was furnished to the Dutch government and everybody else on the internet uh never actually said who the initial firm was I did not ever find that out but I would love to know um and that report basically just showed that some server sitting out there in their infrastructure in uh in in one of the dmz's uh had been compromised by an unknown entity using a known

vulnerability um in the dot net nuke software that that server Ran So yet again another known known vulnerability that hadn't been patched on a server sitting out there wide open on the internet um that story should be very familiar now at this point um it was discovered that the Rogue one of the Rogue certificates had been verified by an IP address originating in the Islamic Republic of Iran so basically when you're out there navigating around on the web um your browser whatever it will be will say yep that's fine and good I see that certificate I verified the chain it does look valid but there's a little bit more that goes on in the background that

needs to happen in order for that certificate um to actually be verified so they saw that that some browser in Iran had requested to verify that certificate August 28th as we know we talked about this already that is when our friend posted that innocuous message in the Google product forums August 29th that certificate was revoked and then August 30th there was another it firm called Fox I.T that was hired by Digi notar they kind of specialize in um digital forensics and things like that and they were the author of the final report that was eventually published and furnished everybody so why do we need Certificate transparency logs um the aftermath of the digi notar breach

531 certificates were issued between July 10th and July 20th used in um uh monster in the middle attacks against Google Gmail Yahoo Skype Mozilla um Microsoft tour and ever and and others um Kaspersky uh researcher um I'm not even going to try to pronounce that last name basically said um in a public Blog blog post according to digi notar they are not able to track which Rogue certificates they generated so they issued 531 they had no idea what those certificates were there was nothing actually reconciling not a single log file saying I issued a certificate for Gmail I issued a certificate for login.yahoo No Such accounting um if you don't know what you're issuing you're probably not counting how many

are issuing um so they didn't know how many Rogue certificates were out there um either did you know Tire performs no logging of the certificates they create or their logs got cleaned out in the attack so a little bit of benefit of the adult there um Chris wazinski from Sophos said they found all of this um they found all the certificates except for the google.com one what other sites were at risk from visiting earlier were those certificates for Microsoft Yahoo or PayPal spoiler alert they were when he published that the full list of certificates had not been yet found out but not a good look so CT logs um trust no public record of certificates issued

not who issued it not requested not who requested it um not how many did they issue or was that the only one if you have one Rogue certificate issued logic kind of follows that there was probably a lot more but without any of those kinds of Records you don't know problem number two it takes a while to revoke certificates um you can you know a CA can revoke a certificate an end user can request to certificate be revoked um but it's not instantaneous um and the third part notification how do uh end users know that that certificate has been revoked uh there isn't or there was not at the time a very good valid mechanism for

um someone here and someone in New York um reconciling those um so as a domain owner you have no idea um you're just kind of blindly trusting at that point that Cas are doing their job like they said they would um and that they were only issuing certificates that were requested and they weren't issuing certificates for competitor for your competitors um but users also don't really have any way of knowing is when they go to mail.google.com to log into their uh Gmail is that actually is what they're logging into actually Google the only thing that you have is that certificate um and if it says it's from Google you're probably not going to look too

much further into that certificates take a while to revoke crls have existed for quite a long time a client a web browser in this case would generally download a crl list from a certificate Authority or a crl issuer um maybe once a day maybe once every couple of days um it's kind of expected that your browser will check those um it'll search through the list and if the domain that you're navigating to is on that list it will prompt that but your browser may be out of date on that list refresh so no instantaneous mechanism to revoke a certificate right away you could be waiting a day or two for that to finally show up on your browser as

having been revoked notification we talked about that how are you notified that the certificate has been revoked whatever this is over here how many times a day do you see that at work um I log into firewalls all the time certificate validation errors do I look at them I have in the past I don't regularly I'll admit that um but you as a user you probably see that you go to a hotel you try to connect to the Wi-Fi they're running a captive portal says please click here to continue so you got to like click around and Google or in Chrome or Mozilla click Advanced it's different for each one too which is also kind of frustrating

um probably just close browser and walkway which I guess is kind of the intended purpose of that make it too hard to do unsafe things so um the need has been demonstrated uh we need a better accounting mechanism for this it needs to be publicly available needs to be trusted um we probably shouldn't let the cas run it they've kind of in the past demonstrated that they're not some of them are not to be trusted um so how does this all work um a website owner basically used them in a CSR or um a request they'll issue a pre-certificate which is a certificate it's just not a real one there's a couple of bits and bytes in

there that indicate that it's not to be used as an actual secure certificate um the ca then publishes that certificate that pre-certificate to a log um that log takes that pre-certificate it basically stamps it with a timestamp on there and sends it right back to the ca now that that um certificate timestamp is in that certificate it has been published to a log it has been recorded as being in that log the ca can now send that certificate on to you to use on your website um and then the browsers and user agents will monitor those certificates um and then all of these certificate logs that are out there are all cryptographically monitored so not to

get too in-depth on that it's basically a Merkle tree hash um the blockchain um so they're cryptographically monitored they are append only you cannot once something is published to a CT log remove it no matter how much you beg and plead once it's in there it's in there forever um and uh no no edits allowed so CT log providers the big ones out there cloudflare digicert Google let's encrypt satigo trust Asia there's a few others I didn't really record them we have over here the certificate um the timestamp requirements so in order for a certificate to be trusted in the Chromium browser the CT the the SCT has to be published to at least one log

um and it can um so sorry for a certificate validity length of less than 180 days it has to be published into two different CT logs so those would ideally match up and if they're issuing a certificate for longer than 180 days which is pretty difficult to do now these days you can still get them on an EV certificate but it has to be published to three different logs so the ca can publish it to the let's encrypt log they can publish it did you certain they can publish it it to sectigo if they'd like to and that will return in Chrome uh completely valid certificate there's a big red bar there for Mozilla they have not yet at this

point today's date instituted a CT log requirement in the Mozilla browser Safari has one Chrome has one um not sure what Mozilla is doing but it's fine we'll get there they'll get there certificate logs um the buy the providers Google maintains a whole bunch let's encrypt has a few Cloud flares got a couple um did you search has a couple there's a lot of certificates that are requested every day there's been 9.2 billion certificates published since 2013. so you can't stick them all into one file that would just make them too long so what basically what ends up happening is that certificate the certificate logs themselves are are sharded by the year of the certificate

expiration is that kind of track for everybody if your certificate expires in 2024 it will be published into the for example argon 2024 certificate log um I thought this was kind of a useful and interesting certificate or I'm sorry a um uh graphic here just kind of showing the uptake of the number of certificates published into each log you can definitely see that that all started to take off there in 2019 and they've basically doubled their traffic every year since um I pulled this graphic from cloudflare they um have published some useful information here um just basically talking about uh you know sorry that's 4.1 trillion um valid certificates floating around out there uh for 8.5 trillion domains

um they issue a lot of certificates every day let's encrypt uh we'll issue between five and six million certificates a day so that's a lot of certificates being issued um and then this also will show the um the log utilization by large Cas and this is basically just kind of showing here that some Cas prefer publishing to others to certain CT logs over others and some of them are just kind of round robin they'll publish to all of them the CT log stream if you want to go out there and monitor the CT logs yourself the best way to do that that I found up to this point is a a service from calidog um it's uh search

stream servers written in Elixir you can plug it in it'll monitor every CT log out there if you want to go parse the CT logs for your own domains be my guest it's kind of a pain though so I've got up here um a couple of um interesting useful utilities they're probably the best well-known one no well-known one is uh crt.sh that's bisectigo uh Cali dog also publishes a bunch of libraries for python go JavaScript um and they'll laugh at you if you try to use Java it's on their website I didn't make that up but there's also cert spotter that's by SSL mate or cert Eagle there's a few others out there meta has a search if

you own a domain you can go check plug your domain in you can see how many certificates have been issued for your domain if you'd like to monitor the pre-logs you'll need to use the fort or sorry the certificate transparency log go by Google they forked the go libraries for ASN encoding and crypto x509 because the scts don't really conform to valid spec so they had to make some adjustments there I've got a quick demo here I want to run through that I've got just about 10 minutes left and so basically what I wanted to take everybody through um is the process of requesting a certificate through let's encrypt and then using that on a honey pot showing that

basically once we go issue a certificate there are eyes watching out there so let me just go ahead and get out of the slideshow real quick and we'll go ahead and get that started

is that big enough oh I'm sorry that's on my screen this might be interesting okay

a big black box

here

so we're going to go ahead and generate a cert for a domain that I registered a little while ago and that will basically point to a Honeypot that I have thank you

all right and we're off and going so as you can see up there um I've registered the domain b-sides uh SF 2023-ct logs.com I've generated a random sub domain for that and that didn't quite work I have another one for this hold on one second

I lost my mouse that would probably be a whole lot easier wouldn't it

hey there we go

foreign the original demo didn't want to work same setup uh randomly generated subdomain we'll be publishing an a record to cloudflare and then using that for text-based verification through let's encrypt um there goes the DNS Challenge and then that will go ahead and start stop and we'll we'll refresh everything in just one moment this Honeypot that's running I found a very good utility I was going to write my own and realized that that was way more effort than I wanted to put into this I'll put it in the uh in the slides here but there's a very very good um Honeypot utility out there published by Deutsch Telecom it's called teapot CE the letter t pot and then the letters c

e that basically has 30 or 40 some odd honeypots that all run in different Docker containers they've got a fantastic web UI we'll go through that in just a moment but basically what that does is it spins up a whole bunch of Docker containers that are meant to look like elasticsearch or redis or um a whole bunch of other things it will also monitor the um SSH telnet logins and things like that I will go ahead and grab this here

I clicked through it I just said that right oops yeah I clicked the wrong one let's try that again this should be the right one you might have to wait just a moment here for Cabana to come back up it's uh it's been collecting attacks for quite a while so the index is is rather large this is the general kind of just teapot user interface um and then we'll go ahead and just take a look here at the dashboards

I'm sorry

to be what we want

all right so

once we load in um there are quite a few dashboards we'll give that just a moment there to catch up talk about those there real quick

so in the week and a half that this has been running um they well in the last 24 hours um this particular Honeypot has been attacked 17 and a half thousand times you can see these rather large spikes in here this is while I was um working on the presentation this morning and last night as well um and so oops

let's just look at the last uh two hours here

so if we go out and issue a certificate um pointing at this IP address we can see that there's been about a thousand instances for this Purdue so each the the top bar up here is basically just representing each of those is a different honey pot that is running on the system we've got a very nice map of generally speaking where those attacks are coming from and the user agents um country of origin what kind of attack it was going and then the rather amusing tag cloud of usernames and passwords down there that have been attempted to be used to log into SSH and some of the other https logins there's um there's a Blog that's

running on there there's a Cisco ASA firewall that's running on there and so this is basically just collecting all of the attempts there are another few dashboards in here if you really want to drill into other um honey pots by buy Honeypot in there you can see exactly what that had been collecting and everything else the

come on it's just taking a little while um I wish I had some more time I will leave this up if you want to take a picture of the URL up there you're welcome to do that might be a little bit of a CTF to figure out what the actual web and password is on there

okay let's uh we'll get back to the demo here real quick or sorry the the presentation um we'll talk about red team and blue team real quick and then we'll have a minute or two for questions at the end so so if you find yourself defending [Music] um on the defensive side of the security space um my recommendations would be to find some sort of tool or tool out there whether it's paid or free there's a whole bunch of self-hosted options um and I'd like to press impress on you that if you go out and monitor your organization or your own domains just once a month or once every quarter that is far better than doing absolutely

nothing at all you probably don't need to put the effort into monitoring the actual live stream of CT logs on Akron 15 20 30 minutes should be probably just fine how long it takes you to find out if somebody in your organization if sales has gone out and stood up another subdomain probably doesn't matter too much how long it takes you to find that out if fixing that problem is going to take a few months um you can also see if CAA records work for your organization for your use case a CIA record basically says only this provider is allowed to issue certificates so you can say only let's encrypt for these subdomains I'm getting the old stop sign here I do

apologize that we didn't quite get to finish I'll stick around or at least outside if you have some more questions I've uploaded the rest of these slides and everything else to the presentation are too too scared so if you would like to go through these you're more than welcome to peruse them at your leisure thank you so much for coming today and enjoy the rest of your day [Applause]