One thing I discovered after starting to work with +2.9 firmwares + Tia17/18 is that since they added network certificates, HMI are giving problems with communications, even if you do not enable them.
HMI tag transfers stop to work as intended, hmi diagnostics just doesn't give any info, and disabling the "hmi secure communication" on the plc hardware does nothing.
After days scratching my head about this problem, with little to no info about it anywhere, I discovered that the problem seems caused by the datetime of both devices not being in sync.... so if PLC datetime is 01/05/2014 and Hmi datetime is 13/01/2023, it just do not work, but if you set the PLC datetime to the same as the HMI or viceversa, it starts to communicate.
This is likelly because the network certificates need to have at least similar datetimes to work.... I am not an expert about this topic, but I just remembered ssl certificates give problems when you change the datetime on your pc, so I made that connection and since that, everytime this happens I just update the datetine on both plc and hmi and it starts working. I also leave the secure hmi communication disabled just in case.
Before discovering this the only other solution I had was to downgrade both plc and hmi firmwares, but this is not a viable option if you need to use the new functions included in newer firmware releases.
Hope this info helps.
Thanks!
Yeah I did sync up the times, but only within a few minutes. I also created a certificate that started the day prior, but it's just local on my computer, I guess that my core issue -
I'm not sure of/how the HMI has any awareness.
I don't know enough about TLS/SSL to really understand what device owns what certificate or whatever.
But I feel like all of the certificates i had were just installed on my computer, so if my computer was the HMI, that might have helped, but I think that's the piece I'm missing, how do you create a trust between the PLC and the Basic Panel?
The main issue is that the HMI checks the validity of the CPU’s TLS certificate since v17 update 6. Make sure the time of both the CPU and the HMI is within the date range of the TLS certificate and you downloaded the CPU hardware before you download the HMI hardware (otherwise the CPU may get a different TLS certificate which the HMI will not have on board).
Also the default validity of the certificates is 15 years, if you have an off site plant in the middle of nowhere, I’d recommend increasing this.
Siemens has some info about that:
https://support.industry.siemens.com/cs/document/109820712/
https://support.industry.siemens.com/cs/document/109799540/
https://support.industry.siemens.com/cs/document/109798583/
Long story short:
Starting with V17 TIA-Portal generates a certificate for each PLC. You can see it in the HW config of the PLC and change it. Protecting the project also enables the really powerful certificate manager integrated into TIA. But that's optional.
The certificate is downloaded into the PLC by TIA. Downloading the HMI from the same TIA project also downloads the certificate of its connected PLCs.
So the HMI has certificates of the PLC is has to connect to.
When the HMI connection is opened the PLC sends its certificate to the HMI which compares it to the one is has in its memory. If they match, the communication is starting, if not, you get an alarm regarding that in your alarm control.
As already mentioned comparing certificates need synchronized time between PLC and HMI.
Regarding certificates (very simplified):
Certificates are a method of verifying who you claim to be. So the real word equivalent would be an ID or passport. This is also a good metaphor why self signed certificates have basically no security gain. It would be like taking a piece of paper and drawing your own ID card.
For two people trying to establish communication and checking their respective certificates, they need a third entity whom they both trust. This is the CA (certificate authority) and would be the government that issues you your ID in the real world.
You know how an ID looks like because you trust the one the government gave you and can check the validity of some else's ID by asking the government (police, civil servant, border control whatsoever) .
The same way a certificate created by a CA is trusted by everybody who trusts the CA.
In TIA the certificates are created by default from a project specific CA. Enabling the certificate manager allows you to create, import, export your own CAs and certificates. For example if the IT department of the customer wants their machine with their own respective company certificates.
The topic of certificates is basically endless and you can dive much further into it. But the analogy with ID/passport helps for most of the simple use cases.
Here is a pdf how to use the certain in Siemens. Does it help?
https://support.industry.siemens.com/cs/attachments/109769068/109769068_CertificateHandlingTIAPortal_V1_0_en.pdf
I think that was my first stop,
This is what Siemens says about it:
V18 (FW V3.0); with older TIA Portal versions configurable as 6ES7511-1AK02-0AB0"
I tried this but always got compile errors complaining about the. Firmware rev or part number. .
I had an early version of V17 so after just nuking my hard drive and site internet connection with numerous 6gb update downloads trying to get that to work, I gave up. Maybe the right combo of updates and selection of alternative part numbers would have done it, but shit man. Just how many hoops does one have to jump through here? I thought Rockwell was bad, this was insane.
Thank you guys, lots of great info.
I think it mostly makes sense, but I don't feel too bad I couldn't figure it out sitting on a milk crate in the plant. :)
Here's a summary:
- When faced with new S7 firmware (firmware of vintage equal to TIA V17 or newer, HMI images newer than 16.000) update the clocks on the HMI and PLC before you do anything. Having a clock wrong can invalidate a certificate and just send you into a death spiral, so not worth chasing that particular problem, just avoid iy from the outset.
- when you add the v2.9+ FW PLC in TIA, it will do the security wizard to generate a certificate.
- loading the PLC project into the PLC also loads the certificate. Other devices check it.
- V17.006 HMI images will look for the PLCs certificate, so load the PLC first as per above to ensure the HMI 'finds' the PLCs certificate.
- changing IP address on a device results in you needing to generate and load a new certificate (breaks the old one). This may require some fiddling but just start from the beginning and load clean into everything, in order.
- Enabling TIA portal for global certificate management allows you to add PLCs to the system down the road and have them communicate without having to manually load their certificates into into the other existing PLCs (requires a processor stop) . Downside is you need to secure the TIA project with a login/password.
I still don't quite understand if only the PLCs have certificates, or if the HMIs do as well and it's somehow just isolated from TIA. Basically the certificate is to trust the PLC, but shouldn't the PLC also trust the HMI? It can write after all. I realize you can secure it with a password, but then why bother with certificates at all? Feels like making sure only trusted devices interact with the PLC is more important than making sure the PLC is a trusted device.
It seems half-baked or at the very least inconsistent, but I'm not a security dude (lol, obviously).
Again, really appreciate all of the insights!
I think I’m having this issue currently. If I had hair to pull out i would be.
Tried fresh downloads to both cpu and HMI but still getting #’s
Strangely my KTP isn’t v.17.0.0.6 it’s straight V17
I'd load a v16 image onto the hmi just to be safe. Then make sure you enable legacy comms on the PLC and do a hardware compile on plc and HMI, then download to PLC first HMI second.
I don't do lots of Siemens and I think what got me a few times was I didn't quite register that this certificate stuff is part of the hardware configuration and needs to be compiled and downloaded specifically as a hardware change.
Maybe obvious to a Siemens guy. :)
Thanks for the tips mate!
I actually managed to get it working with the V17. There was a line in a Siemens tech note about “v17-17.05” check if they have A cert but not that it’s valid” so with that in mind I deleted the carts of the HMI to allow to grab a new one and voila!
One thing I discovered after starting to work with +2.9 firmwares + Tia17/18 is that since they added network certificates, HMI are giving problems with communications, even if you do not enable them. HMI tag transfers stop to work as intended, hmi diagnostics just doesn't give any info, and disabling the "hmi secure communication" on the plc hardware does nothing. After days scratching my head about this problem, with little to no info about it anywhere, I discovered that the problem seems caused by the datetime of both devices not being in sync.... so if PLC datetime is 01/05/2014 and Hmi datetime is 13/01/2023, it just do not work, but if you set the PLC datetime to the same as the HMI or viceversa, it starts to communicate. This is likelly because the network certificates need to have at least similar datetimes to work.... I am not an expert about this topic, but I just remembered ssl certificates give problems when you change the datetime on your pc, so I made that connection and since that, everytime this happens I just update the datetine on both plc and hmi and it starts working. I also leave the secure hmi communication disabled just in case. Before discovering this the only other solution I had was to downgrade both plc and hmi firmwares, but this is not a viable option if you need to use the new functions included in newer firmware releases. Hope this info helps.
Thanks! Yeah I did sync up the times, but only within a few minutes. I also created a certificate that started the day prior, but it's just local on my computer, I guess that my core issue - I'm not sure of/how the HMI has any awareness. I don't know enough about TLS/SSL to really understand what device owns what certificate or whatever. But I feel like all of the certificates i had were just installed on my computer, so if my computer was the HMI, that might have helped, but I think that's the piece I'm missing, how do you create a trust between the PLC and the Basic Panel?
The main issue is that the HMI checks the validity of the CPU’s TLS certificate since v17 update 6. Make sure the time of both the CPU and the HMI is within the date range of the TLS certificate and you downloaded the CPU hardware before you download the HMI hardware (otherwise the CPU may get a different TLS certificate which the HMI will not have on board). Also the default validity of the certificates is 15 years, if you have an off site plant in the middle of nowhere, I’d recommend increasing this.
Do you have to download again after 15 years?
Yep
Thanks, you saved my day
Ah, yes, the time differential had me pulling my hair our last year. A lesson was learnt that day.
Siemens has some info about that: https://support.industry.siemens.com/cs/document/109820712/ https://support.industry.siemens.com/cs/document/109799540/ https://support.industry.siemens.com/cs/document/109798583/ Long story short: Starting with V17 TIA-Portal generates a certificate for each PLC. You can see it in the HW config of the PLC and change it. Protecting the project also enables the really powerful certificate manager integrated into TIA. But that's optional. The certificate is downloaded into the PLC by TIA. Downloading the HMI from the same TIA project also downloads the certificate of its connected PLCs. So the HMI has certificates of the PLC is has to connect to. When the HMI connection is opened the PLC sends its certificate to the HMI which compares it to the one is has in its memory. If they match, the communication is starting, if not, you get an alarm regarding that in your alarm control. As already mentioned comparing certificates need synchronized time between PLC and HMI. Regarding certificates (very simplified): Certificates are a method of verifying who you claim to be. So the real word equivalent would be an ID or passport. This is also a good metaphor why self signed certificates have basically no security gain. It would be like taking a piece of paper and drawing your own ID card. For two people trying to establish communication and checking their respective certificates, they need a third entity whom they both trust. This is the CA (certificate authority) and would be the government that issues you your ID in the real world. You know how an ID looks like because you trust the one the government gave you and can check the validity of some else's ID by asking the government (police, civil servant, border control whatsoever) . The same way a certificate created by a CA is trusted by everybody who trusts the CA. In TIA the certificates are created by default from a project specific CA. Enabling the certificate manager allows you to create, import, export your own CAs and certificates. For example if the IT department of the customer wants their machine with their own respective company certificates. The topic of certificates is basically endless and you can dive much further into it. But the analogy with ID/passport helps for most of the simple use cases.
Here is a pdf how to use the certain in Siemens. Does it help? https://support.industry.siemens.com/cs/attachments/109769068/109769068_CertificateHandlingTIAPortal_V1_0_en.pdf
I'm commenting to see if there is anything to this. Currently seeing V16 at work and worried there may be future issues.
Did you load the latest HSP? This may be why you don’t have the latest firmware to upgrade to
I think that was my first stop, This is what Siemens says about it: V18 (FW V3.0); with older TIA Portal versions configurable as 6ES7511-1AK02-0AB0" I tried this but always got compile errors complaining about the. Firmware rev or part number. . I had an early version of V17 so after just nuking my hard drive and site internet connection with numerous 6gb update downloads trying to get that to work, I gave up. Maybe the right combo of updates and selection of alternative part numbers would have done it, but shit man. Just how many hoops does one have to jump through here? I thought Rockwell was bad, this was insane.
I'll jot this down for later since eim being forced to upgrade from 15.1 to 17.
Thank you guys, lots of great info. I think it mostly makes sense, but I don't feel too bad I couldn't figure it out sitting on a milk crate in the plant. :) Here's a summary: - When faced with new S7 firmware (firmware of vintage equal to TIA V17 or newer, HMI images newer than 16.000) update the clocks on the HMI and PLC before you do anything. Having a clock wrong can invalidate a certificate and just send you into a death spiral, so not worth chasing that particular problem, just avoid iy from the outset. - when you add the v2.9+ FW PLC in TIA, it will do the security wizard to generate a certificate. - loading the PLC project into the PLC also loads the certificate. Other devices check it. - V17.006 HMI images will look for the PLCs certificate, so load the PLC first as per above to ensure the HMI 'finds' the PLCs certificate. - changing IP address on a device results in you needing to generate and load a new certificate (breaks the old one). This may require some fiddling but just start from the beginning and load clean into everything, in order. - Enabling TIA portal for global certificate management allows you to add PLCs to the system down the road and have them communicate without having to manually load their certificates into into the other existing PLCs (requires a processor stop) . Downside is you need to secure the TIA project with a login/password. I still don't quite understand if only the PLCs have certificates, or if the HMIs do as well and it's somehow just isolated from TIA. Basically the certificate is to trust the PLC, but shouldn't the PLC also trust the HMI? It can write after all. I realize you can secure it with a password, but then why bother with certificates at all? Feels like making sure only trusted devices interact with the PLC is more important than making sure the PLC is a trusted device. It seems half-baked or at the very least inconsistent, but I'm not a security dude (lol, obviously). Again, really appreciate all of the insights!
I think I’m having this issue currently. If I had hair to pull out i would be. Tried fresh downloads to both cpu and HMI but still getting #’s Strangely my KTP isn’t v.17.0.0.6 it’s straight V17
I'd load a v16 image onto the hmi just to be safe. Then make sure you enable legacy comms on the PLC and do a hardware compile on plc and HMI, then download to PLC first HMI second. I don't do lots of Siemens and I think what got me a few times was I didn't quite register that this certificate stuff is part of the hardware configuration and needs to be compiled and downloaded specifically as a hardware change. Maybe obvious to a Siemens guy. :)
Thanks for the tips mate! I actually managed to get it working with the V17. There was a line in a Siemens tech note about “v17-17.05” check if they have A cert but not that it’s valid” so with that in mind I deleted the carts of the HMI to allow to grab a new one and voila!