
Cisco devices must regenerate self-signed certificates before 2020 - black_puppydog
https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html
======
yardstick
Ignoring for a moment the fact that they hard coded an expiration date:

This serves as a good reminder of why it’s a bad idea to set expiration dates
at the end of a year, where lots of people are on leave for the holidays (this
notice came out only 2 days ago). Instead try sometime less complicated, like
mid March or Sept.

~~~
raxxorrax
x.509 certs all have a validity period. Of course they could have set them to
2099, but as far as I know you cannot change the validity without reissuing
the cert.

~~~
tialaramex
It's called notAfter and since it's part of the signed document you cannot
change it without invalidating the signature. In a custom system the issuer
could (but probably shouldn't) sign a document which is identical save for the
notAfter date, but in the Web PKI this would be a serious miss-issuance and
have consequences.

By convention the notAfter field is filled out in Zulu timezone (ie UTC) and
so these will expire simultaneously around the world.

------
phicoh
What I find bizarre is software that accepts a self-signed certificate only to
then reject the cert because it has expired. What security problem are they
trying to solve there?

~~~
saurik
The reason to expiration dates on certificates is so that a compromised
private key has a limited lifetime of applicability, under an assumption that
you will be actively rotating keys and issuing new certificates that expire at
later points in time. As far as I would think this consideration has nothing
at all to do with whether the certificate is self-signed.

~~~
phicoh
The model in most software that allows self-signed certs is that you eiter
disable checking all together, or that the user accepts a specific cert.

If you disable checking all together, then an attacker doesn't need to
compromise a private key. Any impersonation attack will just work.

If you require the user to accept a specific cert (and store that information)
then you can just as well let the user accept an expired cert.

The current situation just creates a lot of hassle for people without any
security benefit.

Key rotation is completely separate from the lifetime of a cert. You can renew
certs while keeping keys constant forever. In practice, if your key gets
compromised and you have to wait for the cert to expire, then you have a very
big problem. Even with letsencrypt it is likely more than a month before the
cert expires.

~~~
AnIdiotOnTheNet
> The current situation just creates a lot of hassle for people without any
> security benefit.

In my experience, many "security" people see this as the purpose of their job.

------
TrueDuality
Oh god. Thanks Cisco for dropping this 11 days before the end of the year.
Wooo, glad I saw it here at least...

------
black_puppydog
> Self-signed X.509 PKI certificates (SSC) that were generated on devices that
> run affected Cisco IOS® or Cisco IOS XE software releases expire on
> 2020-01-01 00:00:00 UTC. New self-signed certificates cannot be created on
> affected devices after 2020-01-01 00:00:00 UTC. Any service that relies on
> these self-signed certificates to establish or terminate a secure connection
> might not work after the certificate expires.

------
rb808
Certificate management is such a huge problem for big organizations. Does
anyone have guidelines on how to do it properly? You really need a way to
track who is using what and how they automatically get renewed a long time
before expiry.

My view now is that certificates should be renewed very often - like every
month, if you see something within 6 months of expiry there is a problem.

~~~
hylaride
I'd like to know as well. At my work we had to partner with a major bank and
they demanded a fully signed (sigh) client certificate for the integration.
The way their API works means that we have to do a planned hard-cutover before
the certificate expires. There's a 60% chance that we'll have trouble reaching
out to the right people when the time comes.

Ugh.

~~~
uxp
This is a common problem in healthcare insurance. API connections will stop
working for about 3 weeks every year as each side performs a complicated dance
of noticing the expiration and updating the systems to accept a new public
certificate.

~~~
ehvatum
Seems to be a thing that happens at big companies in general. I add —-no-ssl-
verify to everything and it saves my ass every single year.

~~~
hylaride
That's ok if you're not worried about man in the middle attacks, but it does
make it a lot less secure.

------
EncryptEntropy
Just had to emergency deal with this issue within a large scale complex ISP
env. Fun times!

Edit: And yes as others pointed out, right into the day or two before holiday
moratorium.

------
jodrellblank
I'm surprised there's no workaround "set the clock back to 2019, generate a
certificate, then fix the clock time". Would that not work?

~~~
NohatCoder
The generated certificate would also expire in 2020, so it would be invalid
immediately.

------
wyxuan
Correct me if I’m wrong, but is this just another measure by Cisco to block
off the second hand market for the equipment?

~~~
oarsinsync
Doubtful. Cisco software code quality isn't the best, even in their specialist
fields (see the number of BGP related bugs that are patched every year,
_still_ ). This looks like just another stupid bug that has already been fixed
in a future release.

~~~
tialaramex
Yup. They have lots of smart people, but something has been badly wrong on the
code quality front for decades. I remember not long after the turn of the
century doing inter-continental live debug sessions with their team because
the multicast IPv6 acceleration (MLD snooping, like IGMP snooping but for
IPv6) they'd shipped was completely broken in our Catalyst 3750s. As usual the
authorised workaround was to disable acceleration, destroying the value added
by Cisco's incredibly expensive product so I was on Transatlantic conference
calls after hours trying to get them to reproduce the issue so they could
actually ship us a fix.

~~~
olyjohn
My theory is that the business is more focused on getting contracts and sales,
and getting in some useless magic quadrant than they are on actually providing
a quality product.

------
mavhc
The certificates on the Cisco WLC only lasted 10 years, you have to upgrade
the WLC and all the access points to a new version that includes a command to
turn off the certificate check. If you want to upgrade an AP after that date
you need to set back the clock first, so much fun

------
tyingq
They seem to be highlighting SIP/VOIP as the main issue. And downplaying ssh
access into the router based on an assumption that most don't use x509 certs
for ssh. Does that sound right?

~~~
tialaramex
Also, you aren't affected if you actually have a CA. This only blows up if you
use the Cisco device's own self-signed certs which it always mints (in
affected versions of IOS) with notAfter 2020-01-01.

For stuff like web tools that might happen by least effort, but for SSH it's a
bunch of extra effort, 90% of the effort of doing it properly, yet with almost
none of the security benefits. Anybody who cares will use their own CA and be
unaffected, anybody who doesn't care never enabled certs for SSH on the Cisco
boxes.

------
loriverkutya
I still remember the time when 1st of January 2020 was so far in the future
that it seemed it will never happen.

~~~
iforgotpassword
I did data recovery on an external drive in 2011. It was pretty bad but I only
needed a dozen files or so, rest was backed up. One of the files restored had
a borked creation time in May 2020. For some reason I never fixed that, so
whenever I accessed that folder and sort by date, that file would be at the
top. This is will stop happening soon. I grew so fond of this quirk that I'm
almost sad.

~~~
exikyut

        touch -d 'Jan 01 2030'
    

I initially thought 2099 but 2030 lets you poke it again in ten years :>

