So there was a problem with a printer which you could connect to via SSL in order to print via IPP.
You go in and configure the printer via a web page like so:
Create New Self-Signed Certificate
Create a new self-signed certificate. Warning: This operation will overwrite the currently installed certificate with a new self-signed certificate.
Create Certificate Request
Create the Certificate Request that you will give to a Certificate Authority. The Certificate Request will be used to generate a certificate for you.
Import Certificate and Private Key
Import a certificate and private key to use as the Jetdirect certificate. (Note: This will overwrite the current Jetdirect certificate and private key.
Export the Jetdirect certificate and private key.
The server was configured for “Create New Self-Signed Certificate “ However, Vista would fail to connect to the server. We would connect to https://10.10.10.34 and Vista fails with an error:
“Windows cannot connect to the printer. Make sure that you have typed the name correctly, and that the printer is connected to network.”
BTW – you know you can ctrl+c when those popup boxes are there and capture the info in them right?
So – why did XP work OK but Vista failed..
Let’s start with some CAPI logging… which I discussed back on march 13 , ’07 — http://blogs.msdn.com/spatdsg/archive/2007/03/13/troubleshooting-pki-problems-on-windows-vista.aspx
The first entry to take note of is this one – spoolsv.exe is the process which is doing a trust verification check
Then we can clearly see that the certificate is not trusted by the Vista machine we are trying to connect with.
There was an option to export the cert from the printer so we do that and import it into the Vista machine trusted root store.
Try again…. Ahh a new error – Ill just paste the relevant section from the CAPI2 logs.
Hrmm this one is a little more difficult.
The printer automatically creates a name like:
CN=HP Jetdirect 0AF8ACE8
And we don’t like the name? The error is : The certificate’s CN name does not match the passed value.
What does that mean?
It means that the passed value https://10.10.10.34 did not match the CN….
It does a check in crypt32.dll for the “server name” ( 10.10.10.34 ) against the CN (HP Jetdirect 0AF8ACE8 ) and fails if they are not the same.
We cannot simply connect to https://HP Jetdirect 0AF8ACE8 as it is not a proper FQDN.
So now we know we can’t get around this and change these check. How to configure this then?
The easiest way to workaround it is to generate a self signed cert which does have the proper names we can connect to.
Per the printer config page we could submit a request to a CA – but if we don’t have one then the procedure outlined below is the next best option..
Get a copy of makecert.exe ( its in the free download Platform SDK )
· Run it like so in order to create a self signed cert which has an exportable key and the proper subject.
makecert.exe -r -pe -n “CN=10.10.10.34” -b 07/01/2007 -e 07/01/2010 -eku 22.214.171.124.126.96.36.199.1 -ss My printer.cer
· The switches to make this work are the:
· –pe switch ( allow the keys to be exportable )
· -r self signed
· -eku – specify Server Auth OID
· You will see a new file called printer.cer
C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin>dir prin*
Volume in drive C has no label.
Volume Serial Number is 108D-3591
Directory of C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin
07/31/2007 10:16 AM 542 printer.cer
1 File(s) 542 bytes
0 Dir(s) 3,574,562,816 bytes free
· Now looking in your personal store via certmgr.msc you should see a cert in there with the Issued by field as “CN = 10.10.10.34”
· Right click on this cert, and export this and include the private keys.
· Now, go to the printer management web page and import the .PFX file you just exported.
· Also take the file called printer.cer – and import it to the trusted root store on the Vista machine.
You should now be able to connect OK.
CAPI2 logging is very very helpful – check it out before you jump to conclusions – it may be more helpful than you realize.