Tag Info

Hot answers tagged

28

Import/Export works differently in Xcode 5 (and Xcode 6 beta). This Apple Developer guide shows you how to do it. Your account is shown under Xcode → Preferences → Accounts, and can be exported by clicking the gear icon () in the lower-left.


13

You can do this from within Xcode. From the Organiser, on the devices tab, you can export your developer profile to a file which you can then import into Xcode on another computer. The step by step process is explained in ...


10

Apple KB article HT3930 explains how to configure SSL for servermgrd, the Server Admin web interface. It applies to Mac OS X Server 10.6 so until Apple updates this article part of the steps are confusing / obsolete. Luckily, on Mountain Lion Server (10.8) servermgrd's certificate is stored in the same location as on Mac OS X Server Snow Leopard: in the ...


8

Firstly you'll need to obtain the SSL certificate, sending it to you via email or grabbing it from a web. Once opened (tapping on it from the email attachment, for instance) an installation process will start. On the Install Profile screen, tap on Install. A warning message saying that Installing this profile will change settings on your iPhone will ...


7

There is no way to add Certificate Authorities to Chrome.app on iOS. The only way to manage them is in Settings > General > Profiles. It seems like this is an issue with Chrome.app that's not resolved yet. See Chrome for iOS ignores trusted root CA certificate. You may get additional help by posting to the Google Chrome Forum (linked before).


7

The answer, as discovered by shizmob, is that Apple moved the location of this preference in Maverics to /Library/Preferences/com.apple.security. So what you need to run is sudo defaults write /Library/Preferences/com.apple.security RSAMaxKeySize -int 8192


7

A report on forums.macrumors.com seems to be fairly similar to yours. This happens as well in Safari 5.1 and is very recent. The solution was to delete: ~/Library/Preferences/com.apple.security.plist


4

I've since solved the problem, though I'm not sure if this is the right answer for everyone. The problem seemed to come from the certificate automatically generated from apple (com.apple.idms.appleid.prd.[large character string]). A quick Google search didn't tell me what this certificate was for, but I'm sure that deleting it was probably not the best ...


4

Check that the date is correct. This is an error that can be received if your date is set utterly incorrectly, typically due to a flat battery prior to install and not being able to connect to an NTP server to correct.


3

Unfortunately, Keychain Access (Certificate Assistant) does not have the ability to include a CRL Distribution Point inside of a certificate's extensions section in certificates that it generates. You'll likely notice that your current CA does not have a CRL distribution point specified (even if you've enabled CRL signing as an allowed usage of that ...


2

You need to import the cert via Server.app; that'll add it to the System keychain and several other locations that allow non-keychain-aware services to use it. I'm not sure why it'd be hanging, but I can think of a few things to try: If it's not a self-signed certificate, you probably need to import the appropriate intermediate certificate(s) by dragging ...


2

Provisioning Profiles can be shared without problems between developers. For them to be valid and usable, though, having both Public and Private keys is needed. The Public key is stored in the Certificate whilst the Private has to be exported from the certificate's creator Keychain App.


2

The actually "certificate" itself is not encrypted. Your private key, which is used with the certificate, is usually encrypted. It is encrypted with the passphrase you chose when you created the private key. You might have done that a while earlier than creating this specific certificate, if you have multiple certificates - so be sure to try "old passwords" ...


2

A friend (who was too lazy to write the answer here) hinted me that the root certificates in Mac OSX are stored in the keychain and suggested two different ways around the problem. In order to make openssl library (used by svn) to locate them, you need to manually export them and store them in /System/Library/OpenSSL/cert.pm. The process is described ...


2

You need to export your private key from Key Chain access of Mac OSX in which certificates are running successfully or from which developer certificate made and download certificates from Apple Developer Portal, it will work as it works for me.


2

Yes the installed certificates are valid, however I would advise updating to the latest version of Leopard and make sure that the compromised Diginotar certificates are uninstalled: This link at ps Enable provides an easy method for this. On Root Certificates, they are by their nature long lived since they are the "Master" certificates and having them ...


2

You can script keychain events from the command line with the security command. On Lion and earlier, the worst that will happen if you delete all the system roots is you won't be able to run software update or use iTunes and other applications that interface with secure web services. It might be easier just to make a keychain file you like and shove that in ...


2

If You want to change set of system root certificates, they are in /System/Library/Keychains/. Example of using security there is in this answer to similar question.


2

It took me a minute to find what he was talking about but near the right corner of the message toolbar you will see an icon that looks like a burst with a checkmark. Click this and it will turn to a burst with an x. Here is a screen shot.


2

Currently this is how the Apple Configurator works - it doesn't have a provision to load a certificate but instead generates self-signed ones automatically. If I run across a way to hack this, I'll link it here, but if you need profiles to arrive with a signed certificate look into Lion server or another MDM solution. In practice - you only see the ...


2

Restore the contents of these three directories from a recent backup: ~/Library/Keychains /Library/Keychains /System/Library/Keychains On my system this comprises 18 files and a subdirectory in the user folder ~/Library/Keychains


2

I think this Apple support article has the list you're looking for: iOS 7: List of available trusted root certificates And StartCom is on there.


1

It looks like you might not have actually "trusted" it, but rather made "exception" for it as detailed here: https://blog.httpwatch.com/2013/12/12/five-tips-for-using-self-signed-ssl-certificates-with-ios/ If you did import the certificate, then the above website shows how to remove the "profile" that contains the certificate. To remove the exception, it ...


1

I finally solved the issue by opening the web sites that misbehaved, one at a time, in Safari. From there you proceed to trust each and every certificate. They are then re-added to your keychain. More can be found in this KB. I'd like to thank @bmike for doing his best to assist. Restoring from backup would probably work (if I had one - silly me).


1

Should I worry about this? You should always distrust SSL connections that are using expired certificates. This could indicate a simple oversight on the part of the website operator or it could indicate a malicious attempt to intercept encrypted communications between the website and your browser. Heed your browser's warnings and don't load the page ...


1

It looks like the profile and associated certificate never made it to your phone. If they had, as you note, you would see them in "Settings - General - Profile." Most likely you attempted to enroll, but there was a network issue (flakey network, blocked ports, problem with the server) which prevented the task from succeeding. SCEP, the protocol which ...


1

Did you perhaps upgrade from an earlier version of OS X? Apparently this error is benign: The X509Anchors keychain is harmless and can be left in place. If you do not use any third-party software that requires this keychain, it can be deleted.


1

See the comments above where the asker reports that they never got this to work. So on iOS 5.1, X.509 certificates will not easily be of use to secure email on iOS without some engineering effort and perhaps not at all.


1

The question appears to be specific to using X.509 for authentication to an IMAP service, which isn't supported by iOS. S/MIME email encryption and signatures can be performed on iOS, but the authentication to mail services will still use username/password over SSL or TLS.


1

From your description, one of two things is likely happening. Here's what's supposed to happen, your IT department should package the certificates you need to "trust" their servers and networks and they should provide them and hopefully not change the certificates every few weeks or months. Better, they could pay for a real certificate that's signed by a ...



Only top voted, non community-wiki answers of a minimum length are eligible