If you auto-enroll an account for an X.509 certificate in a Windows PKI environment, do you get the same certificate (and, by extension, private key) on every computer in the domain that you log into, or does a different certificate get issued for each computer you log into?
I would expect there would be a single certificate that would appear in the CurrentUser certificate store on each computer you logged into. But this is a matter of dispute and I don't have an environment where I can test it.
Are there any subtleties of configuring the certificate template that affect this? Does not using roaming profiles affect this?
If it matters, I am most interested in how this works for service accounts, but I expect it would be the same as for interactive user accounts.
Our PKI is currently Server 2003. It should be migrated to Server 2008 within a year.
Win2K3 does support something called "credential roaming". I haven't investigated it myself, but did come across a document explaining it: http://technet.microsoft.com/en-us/library/cc700848.aspx
Related
I have recently built a two-tier PKI infrastructure. This infrastructure consists of an offline root CA named: xxxx-ROOTCA and an online enterprise CA named: xsxx-SUBCA1.
The server xxxx-SUBCA1 also has an internal web site configured on it to which I want to publish the CRLs.
I have issued a handful of certificates during testing that I would now like to revoke. When I go to manually publish the CRL, I get the following error message: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS-DENIED)
In trying to find a solution to this issue, I have come across several resources that state the computer account of the CA must be given additional rights on share where the CRL list is to be published. I've gone into the share (located at D:\pki on xxxx-SUBCA1) and given the xxxx-SUBCA1$ computer account full control share permissions and full control NTFS permissions. I have also made sure the computer account has the same level of share and NTFS permissions for c:\windows\system32\certsrv\certenroll.
If anyone can help me figure out what I have done wrong here, it would be greatly appreciated.
Best regards,
NTD_1313
You need to give the Cert Publisher group write permission on your share on the web server.
Also, note that (unless this is a lab environment) your web server shouldn't be on the same box as the CA.
I'm debating and need to know the implications of not using the SCEP protocol for the mdm enrolment, more precisely the Identity certificate (the certificate credential used for authentication). I'm talking about the certificate in the Identity section on IPCU, as shown in the image below, with the red arrow.
I wont be pushing down profiles with sensitive informations (like vpn, email, etc configurations and/or passwords).
My use case will be 99%:
Block/unblock apps by rating
Lock/unlock device
Block/unlock web domains
From reading around StackOverflow (here and here) the following scenarios can happen.
If someone get access to the certificate he will be able to impersonate an enrolled device, but he will only be able to receive commands/profiles and not initiate commands/profiles. Am I right?
A man in the middle attack can get access to the certificate
The advantage of using the PKCS12 embedded within the profile is that it is faster to implement and no external dependencies (SCEP server) but I'm not so sure about the disadvantages. So my questions and doubts is:
What can a malicious person do with the private key from the Identity certificate?
Can it be a security breach going with the PKCS12 embedded approach?
This is mostly a question of SCEP vs PKCS12 embedded within the profile, pros and cons.
Here my thought on that:
1) If you are building a prototype or a small not critical service then go with PKCS12.
2) If you are building a serious product (production and touching devices of people with sensitive info) then go with SCEP (you can get a free SCEP servers. It's not that complex).
Frankly, If I was on the dark side (trying to hack it) I don't think that I would attack PKCS12 vs SCEP (it's not the weakest link)
However, let say, I say I decided to try to hack it
I would try to do man in the middle. I will try to capture communicarion, save PKCS12 and password for it
I will use it to authenticate to MDM server.
You are right, I can't trigger any commands, but I can start probing your code to find where you skipped some security checks. Maybe you don't check that a certificate matches a device UUID and so on.
Hopefully, I will find enough security holes to do something (let say trigger actions for other users). Maybe I will send them Wipe command or may be I will try to install a root CA + HTTP proxy configuration to see all their traffic.
Anyhow. I don't think that it's that weakest link and it requires a lot of additional step to get to some interesting stuff. However, if you get there, you can do A LOT.
As a result for a serious product, it will make sense to invest several additional weeks in SCEP.
I've got several hundred users on this enterprise app. I've got 2 which are throwing a NSURLErrorServerCertificateUntrusted and won't talk to the server. I've checked the server and the cert is valid, but that didn't surprise me because this issue only impacts these 2 users.
I've had them check date/time on their iPads and they are set correctly and automatically.
I've had them connect try through both cell network and a local WiFi hotspots. It seems unlikely these two users are always being targeted by a man in the middle attack.
This Question never got an answer and Apple's TN2232 document on Trust offered some common issues, but hasn't gotten me to a resolution yet since mostly these things would impact all users, not just a couple.
missing issuer certificate — For any given certificate (except the trusted anchor), the system must be able to locate the certificate of the issuer.
date problems — For any given certificate, the verify date must be within the certificate's valid date range.
self-signed certificate — For any given certificate, if the certificate is self-signed, it will cause evaluation to fail (unless it's a trusted anchor).
no trusted anchor — The system must be able to follow the path of issuer certificates leading to a trusted anchor.
DNS name mismatch — The DNS name that you're trying to connect to must match the name in the server certificate, as described in the previous section.
Any ideas on what is causing this and how to resolve it? Yes, I could just bypass the security and trust my domain, but that's not really an option I'm willing to entertain.
I'm working on an iOS app with a rails backend, running on a VPS (via my own domain).
My question is: is it insecure to use a self-signed SSL certificate on my server and ignore the warnings from NSURLConnection while communicating with it, considering that this is a private API which is only accessible via my iOS app?
The safe way to go in this scenario is: Sign it yourself and manually add the certificate to the local certificate database of every system you work from, so you don't need authentication to know it's yours. Sometimes this can be done automatically as easily as checking the box "ignore the warning for this certificate" the first time you connect from each system, which will prevent you from seen it again on that system unless the certificate changes.
This way you won't see the warning again, unless it's somebody else's self certificate you're looking at.
Ignoring the warning by default usually means that if somebody else signs its own certificate and presents it to you, you will go along without even noticing. Not a good idea.
I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server.
However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue).
From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).
The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).
The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)
Any idea on how to establish the first layer of security (HTTPS) ?
Ok, so to answer my own question...
It turned out that the security has no fixed scale of measurement.
The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.
In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD).
As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.
So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.
We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.
any opinion ?
regards
https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.
If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)
To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.
Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.
[edit]
Check this post - may have more information about what you're asking to do
[/edit]
[edit2]
Please note that the request is iphone, not OSX - app store approval is an issue
[/edit2]