IIS signs with the wrong Subject Alternative Name? - ssl

I am trying to configure our IIS to serve https over the following websites :
mywebsite
mywebsite.default.corporate.domain
servername/mywebsite
I set up 2 IIS websites hosted on this server.
One is the default and hosts various services, which means that some random bindings are activated (net.pipe, net.msmq, net.tcp), plus http and https.
The other one is mywebsite with 4 bindings : mywebsite and mywebsite.default.corporate.domain both over http and https.
I have generated a certificate in p12 format, with both mywebsite, mywebsite.default.corporate.domain and servername as subject alternative name, imported it in local computer personal certificates, and this is the certificate I am using for all 3 https binding.
I set the friendly name to *mywebsite and I edited the https bindings to match each expected domain.
Both mywebsite and servername/mywebsite work great, but mywebsite.default.corporate.domain shows an invalid certificate in chrome. When I check the details, the only subject alternative name is servername, even though the public key matches the one I get with the other two valid pages.
Following various questions and answers, I tried to set the IP adress in the bindings, tried the certutil -repairestore command and numerous IIS resets. I also tried to split the websites for mywebsite and mywebsite.default.corporate.domain.
If anyone has a suggestion, I am completely at loss here and spent way too much time on this already. I am using cutting edge technology (IIS 7 on Windows Server 2008 R2).
Thanks !
Edit 1 : SSL Diagnostics Tool report as requested (anonymised as per company policy, sorry) :
System Time : Tuesday, June 02, 2020 2:20:52 PM Romance Standard Time
Processor Architecture : x64
OS : Microsoft Windows NT 6.1.7601 Service Pack 1
Microsoft Internet Information Services 7.5
SERVER SSL PROTOCOLS
PCT 1.0 : Enabled
SSL 2.0 : Enabled
SSL 3.0 : Enabled
TLS 1.0 : Enabled
SChannel EventLogging : 1 (hex)
-----
[W3SVC/1]
ServerComment : Default Web Site
ServerAutoStart : True
ServerState : Started
BINDING : http *:80:
BINDING : net.tcp 808:*
BINDING : net.pipe *
BINDING : net.msmq localhost
BINDING : msmq.formatname localhost
[W3SVC/2]
ServerComment : mywebsite
ServerAutoStart : True
ServerState : Started
BINDING : http 184.11.52.120:80:mywebsite
BINDING : https 184.11.52.120:443:mywebsite
SSLCertHash : 8111C2E82C5AD2C3E556D5D523BE8C43C4AC46BB
SSL Flags :
Testing EndPoint : 184.11.52.120:443 - Success
#CertName : *mywebsite
#Version : 3
#You have a private key that corresponds to this certificate.
#Signature Algorithm : sha256RSA
#Key Exchange Algorithm : RSA-PKCS1-KeyEx Key Size : 2048
#Subject : CN=servername.default.corporate.domain, OU=STAR, O=MYCOMPANY, L=Paris, S=Ile de France, C=FR
#Issuer : CN=COMP UniPass Server Authentication 2016 CA, O=MYCOMPANY
#Validity : From Friday, May 29, 2020 6:04:08 PM To Tuesday, July 30, 2024 6:04:08 PM
#Serial Number : 4630C58DA21F1A05A8B348255FD0B168DDF104C3
DS Mapper Usage : Disabled
Archived : False
#Basic Constraints : Subject Type=End Entity, Path Length Constraint=None
#Authority Key Identifier : KeyID=fe 3b 7f 76 62 f8 80 36 04 95 8f 34 0a e1 6d af 72 31 6a df
#Authority Information Access : [1]Authority Info Access: Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2), Alternative Name=URL=http://unipass.mycompany.com/ca/ServerAuthentication2016.crt
#Subject Alternative Name : DNS Name=servername.default.corporate.domain, DNS Name=servername, DNS Name=staruat, DNS Name=staruat.default.corporate.domain, DNS Name=mywebsite.default.corporate.domain, DNS Name=mywebsite
#Enhanced Key Usage : Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), Secure Email (1.3.6.1.5.5.7.3.4)
#CRL Distribution Points : [1]CRL Distribution Point: Distribution Point Name:Full Name:URL=ldap://ldap.unipass.mycompany/CN=ServerAuthentication2016,OU=UniPass,O=COMP?certificateRevocationList, [2]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://http.unipass.mycompany/?crlname=ServerAuthentication2016, [3]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://unipass.mycompany.com/crl/ServerAuthentication2016.crl
#Subject Key Identifier : 86 dd 98 41 1c db fc 08 af d1 e8 5b 04 a8 c0 ba 93 be 6f 2a
#Key Usage : Digital Signature, Non-Repudiation, Key Encipherment (e0)
Certificate verified.
[W3SVC/3]
ServerComment : mywebsite.default.corporate.domain
ServerAutoStart : True
ServerState : Started
BINDING : https 184.11.52.120:443:mywebsite.default.corporate.domain
SSLCertHash : 8111C2E82C5AD2C3E556D5D523BE8C43C4AC46BB
SSL Flags :
Testing EndPoint : 184.11.52.120:443 - Success
#CertName : *mywebsite
#Version : 3
#You have a private key that corresponds to this certificate.
#Signature Algorithm : sha256RSA
#Key Exchange Algorithm : RSA-PKCS1-KeyEx Key Size : 2048
#Subject : CN=servername.default.corporate.domain, OU=STAR, O=MYCOMPANY, L=Paris, S=Ile de France, C=FR
#Issuer : CN=COMP UniPass Server Authentication 2016 CA, O=MYCOMPANY
#Validity : From Friday, May 29, 2020 6:04:08 PM To Tuesday, July 30, 2024 6:04:08 PM
#Serial Number : 4630C58DA21F1A05A8B348255FD0B168DDF104C3
DS Mapper Usage : Disabled
Archived : False
#Basic Constraints : Subject Type=End Entity, Path Length Constraint=None
#Authority Key Identifier : KeyID=fe 3b 7f 76 62 f8 80 36 04 95 8f 34 0a e1 6d af 72 31 6a df
#Authority Information Access : [1]Authority Info Access: Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2), Alternative Name=URL=http://unipass.mycompany.com/ca/ServerAuthentication2016.crt
#Subject Alternative Name : DNS Name=servername.default.corporate.domain, DNS Name=servername, DNS Name=staruat, DNS Name=staruat.default.corporate.domain, DNS Name=mywebsite.default.corporate.domain, DNS Name=mywebsite
#Enhanced Key Usage : Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), Secure Email (1.3.6.1.5.5.7.3.4)
#CRL Distribution Points : [1]CRL Distribution Point: Distribution Point Name:Full Name:URL=ldap://ldap.unipass.mycompany/CN=ServerAuthentication2016,OU=UniPass,O=COMP?certificateRevocationList, [2]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://http.unipass.mycompany/?crlname=ServerAuthentication2016, [3]CRL Distribution Point: Distribution Point Name:Full Name:URL=http://unipass.mycompany.com/crl/ServerAuthentication2016.crl
#Subject Key Identifier : 86 dd 98 41 1c db fc 08 af d1 e8 5b 04 a8 c0 ba 93 be 6f 2a
#Key Usage : Digital Signature, Non-Repudiation, Key Encipherment (e0)
Certificate verified.
BINDING : http 184.11.52.120:80:mywebsite.default.corporate.domain
-----
Edit 2 : Apparently the issue in intermitent which is even more incomprehensible/worrying to me.
Edit 3 : I have a feeling it is actually a client error. When the certificate is valid, the Certification Path is not the same as when the certificate is invalid. I am not sure this is possible but there seems to be 2 different corporate root certificate that chrome chooses from to validate my website certificate, one of which allows the good alias, and the other does not. I will contact the ssl support.
Edit 4 : Wanted to wait a bit to confirm that the issue disappeared for good, and it did. I do not have a good explanation but I think there was a configuration issue on our intranet maybe because my company does some weird man in the middle proxying and it might have been wrong for a while. I really do not have the level of expertise to understand what went wrong so this is yet another useless question on stackoverflow, my deepest sympathies if you end up on this question and expect some help...

Related

SSH protocol with PIC18

We are the company ELINAP (Electronics and Applied Computing), and we are working on the development of programs to comply with the TS13 149 standard of passenger counting systems for public transport vehicles produced by us, those , are made with a microcontroller type PIC18F87J60 (16bits). The purpose of the project is to introduce new management protocols for this standard to our ELINAP products. The standard requires security based on the Secure Shell (SSH) protocol, however, we had difficulty finding this protocol on the TCP / IP stack, so let us ask you these questions:
Is the Secure Shell (SSH) protocol implemented on the TCP / IP stack? And is it supported by the PIC18F87J60?
ELINAP (ELECTRONIQUE ET INFORMATIQUE APPLIQUEE)
Rue Thiébaud, 25000
BESANCON, FRANCE Email:
elinap#orange.fr
Tel: 03 81 88 71 16

Play WS SSL acceptAnyCertificate=true issue

We are using Play WS SSL firsttime and play.ws.ssl.loose.acceptAnyCertificate: 'true' config which intends to be for disabling Hostname Verification.
But for some reason I see , it still does the host verification and I see the following warnings.
August 3rd 2017, 15:02:25.084 *** ClientKeyExchange, DH
August 3rd 2017, 15:02:25.083 *** Certificate chain
August 3rd 2017, 15:02:25.083 ***
August 3rd 2017, 15:02:25.083 Warning: no suitable certificate found - continuing without client authentication
August 3rd 2017, 15:02:25.083 0080: 72 70 72 69 73 65 43 41 30 31 rpriseCA01
August 3rd 2017, 15:02:25.083 [read] MD5 and SHA1 hashes: len = 4
August 3rd 2017, 15:02:25.083 0000: 0E 00 00 00 ....
August 3rd 2017, 15:02:25.083 <Empty>
August 3rd 2017, 15:02:25.083 *** ServerHelloDone
From my understanding,
play.ws.ssl.loose.acceptAnyCertificate: 'true' --> Strict validation
play.ws.ssl.loose.acceptAnyCertificate: 'false' --> Loose Validation
When we set the flag to false , it was able to identity server cert from keystore and does cert validation and other checks, also the handshake was happening as expected.
Where as when we set the loose config with flag true, it's NOT able to identify the server cert and throws no suitable certificate found warning and handshake fails.
For me it doesn't make any sense as it was working in the strict case but fails in the loose case which is strange behaviour.
I can say when the flag is set to true, play uses JDK's SSLEngine implementation but some other implementation in case the flag is false
Any ideas ?
Thanks
Suresh
play.ws.ssl.loose.acceptAnyCertificate: 'true' will disable certificate validation, and that is something you should not do unless you understand what are the implications (read Play Framework - Loose Options for more information).
To disable hostname verification, use this instead:
play.ws.ssl.loose.disableHostnameVerification=true

java.net.SocketException: Broken pipe with JMS/JNDI and MQ series

I configured WebSphere MQ v6.0.1.1 to be accessed by a Java client using JNDI and JMS via SSL. I tried the client and server on different machine, and on the same machine. I didn't get the same exception on the client side but it's related to a connection problem. On the server side I have nothing in the log.
Different machine client side error: Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error
*** ServerHelloDone
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 141
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 DB 7F 1B 78 46 24 D1 B3 7F 8F E4 2B 2D 35 .....xF$.....+-5
0010: 1B EB FF C9 01 C9 EC 12 07 0F F9 88 A9 12 45 77 ..............Ew
0020: 22 AE 79 17 C2 9D 4C 97 04 3E BA 91 1F 14 68 44 ".y...L..>....hD
CONNECTION KEYGEN:
Client Nonce:
0000: 50 76 7B FB 0D 45 F0 8D EF 54 E0 AB 2C 3A D4 7D Pv...E...T..,:..
0010: 24 52 FB FB 4F F4 1D E4 CC 2C 4E BA 8B CA 3E 54 $R..O....,N...>T
Server Nonce:
0000: 00 00 00 00 8F 53 C4 4D 2F 2F 41 AA EB 0A 80 2D .....S.M//A....-
0010: D0 E4 51 2A CC BC EE 94 92 BD CD E0 9B C9 EB 3D ..Q*...........=
Master Secret:
0000: 9D 93 ED F3 8A 97 39 7F 71 5F 34 52 30 A6 8E 38 ......9.q_4R0..8
0010: BC 17 59 28 78 63 AA 66 63 D0 EE 1C C6 54 CA D1 ..Y(xc.fc....T..
0020: F2 F0 ED 7E D7 81 33 C6 E3 1B 7C 46 C0 FB C8 5C ......3....F...\
Client MAC write Secret:
0000: 57 56 3D 05 B1 27 BE 56 A8 FD 07 64 0A 96 62 F2 WV=..'.V...d..b.
0010: AE AF B5 98 ....
Server MAC write Secret:
0000: F5 C7 B2 D2 79 11 90 6C C8 FD 86 8B E5 AE 59 71 ....y..l......Yq
0010: B2 A7 AB D3 ....
Client write key:
0000: 54 FD FD 8B C2 B4 8B 3F 38 23 25 5A 8A 41 26 9B T......?8#%Z.A&.
Server write key:
0000: 6D 9C C0 97 ED 21 3F 0E 0A FB E2 2B EE C0 5F 01 m....!?....+.._.
... no IV used for this cipher
Thread pool thread #0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 182, 85, 56, 238, 250, 233, 155, 119, 224, 254, 23, 196 }
***
Thread pool thread #0, WRITE: TLSv1 Handshake, length = 36
Thread pool thread #0, READ: TLSv1 Change Cipher Spec, length = 1
Thread pool thread #0, READ: TLSv1 Handshake, length = 36
*** Finished
verify_data: { 215, 140, 30, 150, 82, 161, 85, 160, 127, 189, 226, 74 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
Thread pool thread #0, setSoTimeout(120000) called
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 150
Thread pool thread #0, READ: TLSv1 Application Data, length = 56
Thread pool thread #0, WRITE: TLSv1 Application Data, length = 48
Thread pool thread #0, called close()
Thread pool thread #0, called closeInternal(true)
Thread pool thread #0, SEND TLSv1 ALERT: warning, description = close_notify
Thread pool thread #0, WRITE: TLSv1 Alert, length = 22
Thread pool thread #0, Exception sending alert: java.net.SocketException: Software caused connection abort: socket write error
Same machine client side error: Thread pool thread #0, Exception sending alert: java.net.SocketException: Broken pipe
It seems that the client writes whereas the server has already closed the connection.
EDIT:
10/10/12 2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9631: The CipherSpec negotiated during the SSL handshake does not match the
required CipherSpec for channel 'SSL.CHANNEL'.
EXPLANATION:
There is a mismatch between the CipherSpecs on the local and remote ends of
channel 'SSL.CHANNEL'. The channel will not run until this mismatch is
resolved. The CipherSpec required in the local channel definition is
'RC4_SHA_US'. The name of the CipherSpec negotiated during the SSL handshake is
'RC4_SHA_US'. A code is displayed if the name of the negotiated CipherSpec
cannot be determined.
ACTION:
Change the channel definitions for 'SSL.CHANNEL' so the two ends have matching
CipherSpecs and restart the channel. If the certificate in use by one end of
the channel is a Global Server Certificate, then the negotiated CipherSpec may
not match that specified on either end of the channel. This is because the SSL
protocol allows a Global Server Certificate to automatically negotiate a higher
level of encryption. In these cases specify a CipherSpec which meets the
requirements of the Global Server Certificate.
----- amqccisa.c : 851 --------------------------------------------------------
10/10/12 2:26:23 PM - Process(10995.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'SSL.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'SSL.CHANNEL' in the error
files to determine the cause of the failure.
----- amqrmrsa.c : 468 --------------------------------------------------------
Edit 2:
1 : DIS CHANNEL(SSL.CHANNEL) SSLCIPH
AMQ8414: Display Channel details.
CHANNEL(SSL.CHANNEL) CHLTYPE(SVRCONN)
SSLCIPH(RC4_SHA_US)
The Cipher used client side using JMSAdmin:
DEFINE QCF(QCF_NAME) SYNCPOINTALLGETS(YES) HOSTNAME(HOST) PORT(1414) TRANSPORT(client) QMANAGER(MYQMGR) CHANNEL(SSL.CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_SHA)
Base on SSL CipherSpecs and CipherSuites RC4_SHA_US seems to match SSL_RSA_WITH_RC4_128_SHA.
There is a possibility when running the client on the same host as the QMgr to connect using bindings mode (shared memory) rather than over the network stack. Since bindings mode connections do not use the network stack, SSL would make no difference.
Assuming that the client is connecting over the network in both cases, there's nothing about the location of the client on one server or another that would influence the SSL connection other than that the client configurations were different from one instance to the other. The client is still going through the network stack and presenting a connection request to the QMgr's listener. The client finds its keystore the same way and all the QMgr sees is a connection request presented to the listener. So if you are getting different results between the two client instances, look for configuration discrepancies.
My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:
Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port.
Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but does not request one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert.
Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
The difference between the last two steps helps to isolate the problem by testing the SSL credential exchange in only one direction at a time.
You mention that there's "nothing in the log" when this happens. Which log? There are two sets of error logs. One is the server-global log at {WMQ home}/errors and the other is the QMgr error log at {WMQ home}/QMgrs/{QMgr name}/errors. Error log entries are made to the QMgr's error log when the MQ can identify the QMgr associated with the error. However, when an SSL connection is requested, MQ does not know which QMgr the connection has requested until after the SSL connection has completed. Because of this, many SSL negotiation errors on the server side are reported in the global error log.
I'd suggest running through the steps outlined above to determine which SSL credential exchange is failing and then looking for the error log entries in both the QMgr and global error log files. If this does not resolve the problem, please update your question noting the step in the process that fails and any error log entries identified by which log they were found in.
Also, V6 of MQ went out of service as of last month. Moving to a supported version of WMQ client and server would allow you to open a PMR, would provide much better Java/JMS performance, and will allow you to use more secure ciphers such as SHA-2 hashes and the new elliptic curve crypto supported by GSKit 8. Since WMQ V6 is out of support, at most only one additional Fix Pack will be released, after which security vulnerabilities in that version will not be addressed. If you are using SSL, I assume security is somewhat important and that you would want to use a version that will receive fixes if a new vulnerability is discovered.
UPDATE
Responding to the question update regarding the Global Server Certificate, it is necessary to understand how WMQ implements SSL/TLS. When the connection is made, the TLS negotiation (if you specify an SSL , WMQ performs a TLS session using an SSL cipher) follows the spec and the spec allows for a negotiation of the ciphersuite. When a global server certificate is used, the cert can specify a minimum acceptable cipher strength and this influences the negotiation.
When the TLS session is completed successfully, the connection is then handed to WebSphere MQ. Only then does the QMgr check the channel parameters such as "what QMgr is the connection requested for?" or, more importantly, "does the connection's negotiated cipherspec match the channel definition?" Typically it fails based on a mismatch between client and server. With a global server certificate it can fail because of a mismatch between the negotiated cipherspec versus the minimum acceptable as specified by the certificate.
What the error message is saying is that it is possible for the ciphersuite specified by the client to exactly match the cipherspec specified in the channel and still fail to connect because the global server certificate specifies a minimum cipher strength that is greater than that used by the client and the QMgr. There is more on this at Cipherspec mismatches in the Infocenter but in this case the error message is almost as informative as the Infocenter.

Is it possible to send LDAP "requests" via telnet?

I am wondering whether is it possible or not to establish a connection to a LDAP server via telnet (or some other program) and start making requests and receiving responses as I would normally do with HTTP. In fact, the question is more generic and is related to my misunderstanding of network connections and communications protocols. Let me tell you the idea I have in my mind about this topic:
All application protocols define communication protocols (that is, messages that the server is going to understand and act upon its delivery). If I know how the application protocol works, I can establish a connection to the server (daemon controlling that protocol server-side) and start communicating with the server. For example with HTTP I can establish a connection to an HTTP SERVER via telnet and start talking with him with this requests for example:
GET /users/pepito HTTP/1.1
Host: stackoverflow
Content-Type: text/html
I am expecting this procedure to happen with ANY APPLICATION PROTOCOL. Is this concept right??
I have glimpsed the LDAP Protocol Specification RFC but I did not understand the format of the messages. I mean, I was expecting to read something like HTTP Protocol Specification; but it was like too generic. Can you give me an example of how LDAP search could be made?
The LDAP RFC specifies that LDAP messages are ASN1 encoded. This means the messages are binary data in a special format, instead of text, following a special format. This makes it very hard to write ladap-queries by hand with telnet.
You can, somewhat, with a little help from some command-line friends :-)
Here's a hexdump of a simple LDAP query -- it does the equivalent of ldapsearch -x -b "" -s base objectclass=top:
30 0c 02 01 01 60 07 02 01 03 04 00 80 00
30 2c 02 01 02 63 27 04 00 0a 01 00 0a 01 00 02 01 00 02 01 1e 01 01 00 a3 12 04 0b 6f 62 6a 65 63 74 63 6c 61 73 73 04 03 74 6f 70 30 00
Save this to a file called ldap.hexdump, and then you can use nc:
xxd -r -p ldap.hexdump | nc ldapserver 389
If you want to see the output parsed, you can use unber:
xxd -r -p ldap.hexdump | nc ldapserver 389 | unber -m -
Where this might come in handy is if you can't use ldapsearch for some reason and want to use nc or openssl to test out whether an LDAP server is responding properly. It assumes that the server accepts anonymous binds to query the empty base DN (root DSE).

Certificates: Cannot find the certificate and private key for decryption Error when sign

I work in company with many servers and Pcs for developers. Servers are win2003, PC developers Windows XP.
In a server Win2003 named preiis01, in preproduction environment, other people in company install a client certificate using any other user (domainCompany\adminsystems) for logging in server preiis01.
Anyone admin uses the user "domainCompany\adminsystems" for log in server preiis01 (using Terminal Server, Remote Desktop for Windows XP).
the admin user is domainCompany\adminsystems", which installs certificate.
Admin user install it like this:
Session login like "domainCompany\adminsystems"
Certificate is PFX file. Do Install PFX and using Wizard. The key private not check for export.
Input the password and install.
There is an application Web which AppPool Identity is: NETWORK SERVICE account.
web server is IIS 6.0.
in preiis01,
That admin user executes mmc -> Snap in -> Certificates for Local Machine. In node -> Personal -> Certificates, he had seen the client certificate:
Issued To ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1
Issued By FNMT Clase 2 CA
In properties of certificate, the thumbprint: "93 bc a4 ad 58 c9 3c af 8b eb 0b 2f 86 c7 9d 81 70 a6 c4 13"
That admin user executes this commands:
winhttpcertcfg.exe LOCAL_MACHINE\My -s "ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1" -g -a "NETWORK SERVICE"
Result is:
Matching certificate:
CN=ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1
OU=703015476
OU=FNMT Clase 2 CA
O=FNMT
C=ES
Granting private key access for
account: NT AUTHORITY\NETWORK SERVICE
Now, admin user executes this command:
winhttpcertcfg.exe -l -c LOCAL_MACHINE\My -s "ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1"
The result is:
Matching certificate:
CN=ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1
OU=700012476
OU=FNMT Clase 2 CA
O=FNMT
C=ES
Additional accounts and groups with
access to the private key include:
domainCompany\adminsystems NT
AUTHORITY\SYSTEM
BUILTIN\Administrators NT
AUTHORITY\NETWORK SERVICE
NOw, in an aspx page in application web in server Win2003, IIS 6.0, I have this code:
NOte: value for X509Certificate2.HasPrivateKeyAccess() is NO (false) for "ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1" certificate.
ASP.NET application executes using the identity :: NT AUTHORITY\NETWORK SERVICE
lbInfo.Text += "<br/><br/>ASP.NET application executes using the identity :: <b>" + WindowsIdentity.GetCurrent().Name + "</b><br>";
var store = new X509Store(StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
Certificates = store.Certificates;
repeater1.DataSource = Certificates;
repeater1.DataBind();
var nombreCertificado = "ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1";
store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection col = store.Certificates.Find(X509FindType.FindBySubjectName, nombreCertificado, false);
if (col.Count > 0)
{
X509Certificate2 certificate = col[0];
store.Close();
Message.Text = "Certificado " + nombreCertificado + " encontrado en " + StoreLocation.LocalMachine;
FirmarConCertificado(nombreCertificado, certificate);
}
else
{
store.Close();
Message.Text = "El certificado " + nombreCertificado + " no esta instalado en la máquina";
}
public void FirmarConCertificado(string nombreCertificado, X509Certificate2 certificate)
{
try
{
var mensaje = "Datos de prueba";
System.Text.Encoding enc = System.Text.Encoding.Default;
byte[] data = enc.GetBytes(mensaje);
var contentInfo = new System.Security.Cryptography.Pkcs.ContentInfo(data);
var signedCms = new System.Security.Cryptography.Pkcs.SignedCms(contentInfo, true);
var cmsSigner = new System.Security.Cryptography.Pkcs.CmsSigner(certificate);
// Sign the CMS/PKCS #7 message
signedCms.ComputeSignature(cmsSigner);
// Encode the CMS/PKCS #7 message
var ret = Convert.ToBase64String(signedCms.Encode());
Message.Text += "Firmado con Certificado " + nombreCertificado + " encontrado en " + StoreLocation.LocalMachine;
}
catch (Exception ex)
{
Message.Text = "Error al firmar con certificado: " + ex.ToString();
Message.Text += "<br /><br />InnerException: " + ex.InnerException;
}
}
The code fails for me, and I get this error: Cannot find the certificate and private key for decryption.
Error line is:signedCms.ComputeSignature(cmsSigner);
Error al firmar con certificado:
System.Security.Cryptography.CryptographicException:
Cannot find the certificate and
private key for decryption.
at
System.Security.Cryptography.Pkcs.PkcsUtils.CreateSignerEncodeInfo(CmsSigner
signer, Boolean silent) at
System.Security.Cryptography.Pkcs.SignedCms.Sign(CmsSigner
signer, Boolean silent) at
System.Security.Cryptography.Pkcs.SignedCms.ComputeSignature(CmsSigner
signer, Boolean silent) at
System.Security.Cryptography.Pkcs.SignedCms.ComputeSignature(CmsSigner
signer) at
ASP.dgsfp_test_testcert_aspx.FirmarConCertificado(String
nombreCertificado, X509Certificate2
certificate) in
c:\Company\App\Test\TestCert.aspx:line
242
Then, the admin user (I remember, who install the certificate) executes this commands:
FindPrivateKey My LocalMachine -t "93
bc a4 ad 58 c9 3c af 8b eb 0b 2f 86 c7
9d 81 70 a6 c4 13" –c
FindPrivateKey
My LocalMachine -n "ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1" –a
FindPrivateKey My LocalMachine -n
"CN=ENTIDAD COMPANY INSURE SA - CIF A93 - NOMBRE SURNAME1 NAME1"
–a
The result for all 3 commands is the same:
FindPrivateKey helps user to find the
location of the Private Key file of a
X.50 9 Certificate.
Usage: FindPrivateKey [{ {-n } | {-t }
} [-f | -d | -a]]
subject name of the
certificate
thumbprint of the
certificate (use certmgr.exe to get
it)
-f output file name only
-d output directory only
-a output absolute file
name e.g. FindPrivateKey My
CurrentUser -n "CN=John Doe"
e.g. FindPrivateKey My LocalMachine -t
"03 33 98 63 d0 47 e7 48 71 33 62 64
76 5 c 4c 9d 42 1d 6b 52" -c
FindPrivateKey don't get anything, but winhttpcertcfg.exe -l works fine (matching certificate)
We have given privileges to the Network Service user using the winhttpcertcfg.exe tool, and in code ASP.NET (execute under Network Service account) the certificate is found. But fails when sign using certificate.
If someone could give us some information about, or suggestions
update:
User in domain "domainCompany\Pre_Certificado" install Certificate in Store Local Machine.
domainCompany\Pre_Certificado is Administrator, in IIS_WPG group, has Local Policies: “Log on as Service“
I configure AppPool Identity in IIS 6.0 for : domainCompany\Pre_Certificado
ASP.NET application executes using the identity :: domainCompany\Pre_Certificado
I recycle AppPool and execute application, I get System.Security.Cryptography.CryptographicException: Cannot find the certificate and private key for decryption
If I test again, log in session in server IIS, using domainCompany\Pre_Certificado user, I call page in ASP.NET application and all is OK.
(note: log in server IIS using Terminal Server)
But if log off session in server IIS (user: domainCompany\Pre_Certificado), I get the same error:
System.Security.Cryptography.CryptographicException: Cannot find the certificate and private key for decryption
Any suggestions ??
Do the first 2 steps as the same as you would with IIS 7.5 (click here)
Create / Purchase certificate. Make sure it has a private key.
Import the certificate into the "Local Computer" account. Best to use Certificates MMC. Make sure to check "Allow private key to be exported"
Run the below command as an administrator. Replace the following:
Replace [Subject] with the certificate's subject and use quotes if it contains spaces. I think you can also just put the first word as long as there isn't another cert that starts with the same subject.
Replace [Store] with the certificate store you imported to, default I believe is "ROOT" or "MY" on IIS 6, i.e. "LOCAL_MACHINE\ROOT" or "LOCAL_MACHINE\MY"
Replace [computername] with the name of the computer. You might be able to use ".\" notation for [computernam] i.e. ".\NETWORK SERVICE" but I have not tried it.
winhttpcertcfg.exe -g -a "[computername]\NETWORK SERVICE" -c LOCAL_MACHINE\[Store] -s "[Subject]"
Note: If you are running ASP.NET Application Pool under an identity other than "NETWORK SERVICE" you'll need the change "NETWORK SERVICE" in the above command to the identity that you're running the IIS application pool.
Please check this document which would help you to resolve the issue. I would recommend to use following command option:
winhttpcertcfg -g -c LOCAL_MACHINE\My -s MyCertificate -a TESTUSER
May need to grant access to the anonymous user also. If you are allowing anonymous access then the request is running as the anonymous user not network service.