Checking suspicious (root CA) certificates
up vote
5
down vote
favorite
I was just looking at my certificate store and saw a bunch of root CAs that look kind of suspicious; specifically numerous ones that:
- have ALL CAPS text
- use foreign languages/text
- have extremely long expiration dates
- include every certificate purpose possible
I strongly believe that some of these are bad (the Intermediate CA list looks clean, only the Root CA list looks bad.) However, there are enough certificates in the store to make investigating each one a real chore. (I see in the Event Log that Windows has not auto-updated the trusted third-party root list for over two weeks.)
Does anyone know of a way to verify certificates and weed out the bad ones (or at least to manually trigger an update)?
windows-xp security certificate trusted-root-certificates
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
|
show 1 more comment
up vote
5
down vote
favorite
I was just looking at my certificate store and saw a bunch of root CAs that look kind of suspicious; specifically numerous ones that:
- have ALL CAPS text
- use foreign languages/text
- have extremely long expiration dates
- include every certificate purpose possible
I strongly believe that some of these are bad (the Intermediate CA list looks clean, only the Root CA list looks bad.) However, there are enough certificates in the store to make investigating each one a real chore. (I see in the Event Log that Windows has not auto-updated the trusted third-party root list for over two weeks.)
Does anyone know of a way to verify certificates and weed out the bad ones (or at least to manually trigger an update)?
windows-xp security certificate trusted-root-certificates
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
3
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stoppedcryptsvc, deletedcatroot2, startedcryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.
– Synetech
Mar 14 '12 at 19:07
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49
|
show 1 more comment
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I was just looking at my certificate store and saw a bunch of root CAs that look kind of suspicious; specifically numerous ones that:
- have ALL CAPS text
- use foreign languages/text
- have extremely long expiration dates
- include every certificate purpose possible
I strongly believe that some of these are bad (the Intermediate CA list looks clean, only the Root CA list looks bad.) However, there are enough certificates in the store to make investigating each one a real chore. (I see in the Event Log that Windows has not auto-updated the trusted third-party root list for over two weeks.)
Does anyone know of a way to verify certificates and weed out the bad ones (or at least to manually trigger an update)?
windows-xp security certificate trusted-root-certificates
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
I was just looking at my certificate store and saw a bunch of root CAs that look kind of suspicious; specifically numerous ones that:
- have ALL CAPS text
- use foreign languages/text
- have extremely long expiration dates
- include every certificate purpose possible
I strongly believe that some of these are bad (the Intermediate CA list looks clean, only the Root CA list looks bad.) However, there are enough certificates in the store to make investigating each one a real chore. (I see in the Event Log that Windows has not auto-updated the trusted third-party root list for over two weeks.)
Does anyone know of a way to verify certificates and weed out the bad ones (or at least to manually trigger an update)?
windows-xp security certificate trusted-root-certificates
windows-xp security certificate trusted-root-certificates
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
edited Mar 14 '12 at 18:45
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
asked Mar 14 '12 at 18:40
Synetech
56.9k29183317
56.9k29183317
3
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stoppedcryptsvc, deletedcatroot2, startedcryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.
– Synetech
Mar 14 '12 at 19:07
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49
|
show 1 more comment
3
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stoppedcryptsvc, deletedcatroot2, startedcryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.
– Synetech
Mar 14 '12 at 19:07
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49
3
3
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stopped
cryptsvc, deleted catroot2, started cryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.– Synetech
Mar 14 '12 at 19:07
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stopped
cryptsvc, deleted catroot2, started cryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.– Synetech
Mar 14 '12 at 19:07
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49
|
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
0
down vote
You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:
Please note that certificate authorities whose certificates are
included in this package are not in any way audited for
trustworthiness and RFC 3647 compliance, and that full responsibility
to assess them belongs to the local system administrator.
answered Aug 28 '12 at 10:34
tricasse
49238
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
add a comment |
up vote
0
down vote
You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.
answered Nov 28 at 23:30
darmual
5611
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:
Please note that certificate authorities whose certificates are
included in this package are not in any way audited for
trustworthiness and RFC 3647 compliance, and that full responsibility
to assess them belongs to the local system administrator.
answered Aug 28 '12 at 10:34
tricasse
49238
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
add a comment |
up vote
0
down vote
You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:
Please note that certificate authorities whose certificates are
included in this package are not in any way audited for
trustworthiness and RFC 3647 compliance, and that full responsibility
to assess them belongs to the local system administrator.
answered Aug 28 '12 at 10:34
tricasse
49238
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
add a comment |
up vote
0
down vote
up vote
0
down vote
You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:
Please note that certificate authorities whose certificates are
included in this package are not in any way audited for
trustworthiness and RFC 3647 compliance, and that full responsibility
to assess them belongs to the local system administrator.
answered Aug 28 '12 at 10:34
tricasse
49238
You can have a look at Debian's list of certificates, and weed out the ones that are not there; then apply the latest Microsoft CA update and add the ones you have installed manually. But as Debian says:
Please note that certificate authorities whose certificates are
included in this package are not in any way audited for
trustworthiness and RFC 3647 compliance, and that full responsibility
to assess them belongs to the local system administrator.
answered Aug 28 '12 at 10:34
tricasse
49238
answered Aug 28 '12 at 10:34
tricasse
49238
answered Aug 28 '12 at 10:34
tricasse
49238
answered Aug 28 '12 at 10:34
tricasse
49238
49238
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
add a comment |
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
I had already tried deleting all of the certs and installing the latest update, but it didn’t help.
– Synetech
Aug 28 '12 at 15:30
add a comment |
up vote
0
down vote
You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.
answered Nov 28 at 23:30
darmual
5611
add a comment |
up vote
0
down vote
You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.
answered Nov 28 at 23:30
darmual
5611
add a comment |
up vote
0
down vote
up vote
0
down vote
You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.
answered Nov 28 at 23:30
darmual
5611
You can quickly find out which ones weren't included originally by running sigcheck sigcheck.exe -tv *, which compares the root CA in your local computer against a list it downloads from Microsoft. Then it outputs the difference. Those certs which didn't come from Microsoft must have been introduced by yourself or a piece of software (i.e. antivirus for ssl inspection). In my case there was only one I didn't recognize and immediately disabled it.
answered Nov 28 at 23:30
darmual
5611
answered Nov 28 at 23:30
darmual
5611
answered Nov 28 at 23:30
darmual
5611
answered Nov 28 at 23:30
darmual
5611
5611
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f400758%2fchecking-suspicious-root-ca-certificates%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
In the mean-time, I (1) downloaded the latest CA update, (2) manually removed every item from every part of the certificate store, (3) stopped
cryptsvc, deletedcatroot2, startedcryptsvc, and (4) applied the update. Hopefully a less scorched-earth method can be found so that legitimate certificates don't get wiped out like this since they are not included in the update from Mirosoft.– Synetech
Mar 14 '12 at 19:07
Think you got yourself an answer.
– Belmin Fernandez
Mar 14 '12 at 21:46
@BeamingMel-Bin, it’s more of a work-around than a solution. I blasted the whole thing including valid certs that Microsoft doesn’t include. I’m looking more for a program or website that lets you scan or submit certs.
– Synetech
Mar 15 '12 at 1:00
Hm, perhaps I'm misunderstanding what you meant by "bad ones" since it's all based on trust. Do you mean that you believe some are compromised (i.e., the private key is out in the wild)? Otherwise, seems like cleaning out your current store and adding ones you trust or trust by association (Microsoft trusted and your own) is your only option.
– Belmin Fernandez
Mar 15 '12 at 1:37
I mean that it looks like a bunch of bad ones have somehow been snuck in there, ones that allow sites and files to be trusted when they shouldn’t, hence the long expiration dates and full-privileges.
– Synetech
Mar 15 '12 at 2:49