Incorrect public_key for Yeti/Nessie 2024/2025

[AGWA]

These 4 logs don't have the correct public key set in the crt.sh database. It looks like the keys have been inserted as hex with a leading Å character.

i.e. if you take the hex values from the below table, you have to 1) decode the hex, 2) chop off the first character, and then 3) decode as hex again to get the actual DER bytes.

guest@crt/certwatch=> select id,url,public_key from ct_log where id in (95,96,97,98);
 id |                  url                   |                                                                                                                                                                                 public_key                                                                                                                                                                                 
----+----------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 95 | https://yeti2024.ct.digicert.com/log   | \xc53933303133303630373241383634384345334430323031303630383241383634384345334430333031303730333432303030343537423843313646333041343746324545344630443044393630363231333935453337414533344535334333423342383733383543313138304432333045353838344432373845463942423331453243314144454331384638313142313934343538423730303737363032303141373244383832444541453945423143363442
 96 | https://yeti2025.ct.digicert.com/log   | \xc53933303133303630373241383634384345334430323031303630383241383634384345334430333031303730333432303030344446393530303545313043313031463733374533313037344431464642324341393045443332393935463043333946454131443131333131414344314233373339333230433231333343344342353741353238363836334445333935323437434438393139383438334246304630444632314631423038313541353932353433
 97 | https://nessie2024.ct.digicert.com/log | \xc53933303133303630373241383634384345334430323031303630383241383634384345334430333031303730333432303030343244464341323742333642463536393145394645334645383344464343334137453036313532454132434539303541333946323731373831303537303642383136313434384146383342313038303432454430333246303035303231464334313534383441333534443532454232374131363442324131463242363630343242
 98 | https://nessie2025.ct.digicert.com/log | \xc53933303133303630373241383634384345334430323031303630383241383634384345334430333031303730333432303030344632463046304137384238313245303933393342394634324441333834343546423443434544333642424438343337463136343935373837303437464135303133344637453836383346423737383146363036363244363739413735383042373533413738354435424341423437303635354442423544463838413136463338
(4 rows)

[robstradling]

Thanks @AGWA! Now fixed.

It looks like I must've accidentally omitted the 'x' when populating the public_key field for these 4 records. For example, I can reproduce the problem by doing this...

UPDATE ct_log                                 
SET public_key = E'\\3059301306072A8648CE3D020106082A8648CE3D0301070342000457B8C16F30A47F2EE4F0D0D960621395E37AE34E53C3B3B87385C1180D230E5884D278EF9BB31E2C1ADEC18F811B194458B7007760201A72D882DEAE9EB1C64B' 
WHERE ID=95;

...when what's needed is...

UPDATE ct_log                                 
SET public_key = E'\\x3059301306072A8648CE3D020106082A8648CE3D0301070342000457B8C16F30A47F2EE4F0D0D960621395E37AE34E53C3B3B87385C1180D230E5884D278EF9BB31E2C1ADEC18F811B194458B7007760201A72D882DEAE9EB1C64B' 
WHERE ID=95;